[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v1 2/4] libxc: add rt scheduler



On dom, 2014-08-24 at 18:58 -0400, Meng Xu wrote:

> --- /dev/null
> +++ b/tools/libxc/xc_rt.c
> @@ -0,0 +1,90 @@
> +/****************************************************************************
> + *
> + *        File: xc_rt.c
> + *      Author: Sisu Xi 
> + *              Meng Xu
> + *
> + * Description: XC Interface to the rt scheduler
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301 
>  USA
> + */
> +
> +#include "xc_private.h"
> +
> +int xc_sched_rt_domain_set(xc_interface *xch,
> +                           uint32_t domid,
> +                           struct xen_domctl_sched_rt_params *sdom)
> +{
> +    int rc;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_scheduler_op;
> +    domctl.domain = (domid_t) domid;
> +    domctl.u.scheduler_op.sched_id = XEN_SCHEDULER_RT_DS;
>
Aha! So, I was not dreaming about the whole RT_DS thing! :-D

Perhaps then had that discussion about the low level side of things
then. Well, I think that, if the name of the scheduler is RT_DS, it
should be that for libxl and xl as well.

After all, the reason why we're calling RT_DS in Xen, is that we want to
be able to add others RT_FOO, RT_BAR algorithm/schedulers, in future. If
that will happen, we'll need a way to reference them from the higher
layer of the toolstack as well. When we'll have RT_DS and RT_CBS in Xen,
and RT in libxl, to which one the RT in libxl will refer?

So, just push the RT_DS thing all the way up to libxl and xl. As we said
for the Xen part, you can keep the source filenames _rt.c, but functions
and defines needs to be specific.

So, for instance, this file can continue being xc_rt.c, but this
function needs to be called xc_sched_rtds_domain_set()
(or .._rt_ds_domain_..).

> +    domctl.u.scheduler_op.cmd = XEN_DOMCTL_SCHEDOP_putinfo;
> +    domctl.u.scheduler_op.u.rt.vcpu_index = sdom->index;
> +    domctl.u.scheduler_op.u.rt.period = sdom->period;
> +    domctl.u.scheduler_op.u.rt.budget = sdom->budget;
> +
> +    rc = do_domctl(xch, &domctl);
> +
> +    return rc;
> +}
> +
These functions are going to change quite a bit in next version, due to
the interface changes we agreed upon. It'd then be quite pointless to
put much more comments, but, overall, the hcall wrapping, the bouncing
logic, and everything I can see here looks fine to me.

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.