[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 2/4] libxc: add rt scheduler
2014-09-05 6:34 GMT-04:00 Dario Faggioli <dario.faggioli@xxxxxxxxxx>: > 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_..) As to the function name, if I change it to ..._rt_ds_domain_... in xc_rt.c file, do I need to change it in libxl and xl files? In addition, do I need to change the name rt_* functions in xen/common/sched_rt.c in the hypervisor? This seems a lot of (well easy) change, but we need some consensus to avoid changing it back later. :-P > >> + 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. > I will send the next version soon. ----------- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |