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

Re: [Xen-devel] [PATCH v3 for Xen 4.6 2/4] libxc: enable per-VCPU parameter settings for RTDS scheduler



On Tue, 2015-06-30 at 10:57 -0500, Chong Li wrote:
> On Tue, Jun 30, 2015 at 10:32 AM, Ian Campbell <ian.campbell@xxxxxxxxxx> 
> wrote:
> > On Tue, 2015-06-30 at 10:18 -0500, Chong Li wrote:
> >> On Tue, Jun 30, 2015 at 7:22 AM, Ian Campbell <ian.campbell@xxxxxxxxxx> 
> >> wrote:
> >> > On Sun, 2015-06-28 at 21:44 -0500, Chong Li wrote:
> >> >
> >> >> diff --git a/tools/libxc/xc_csched.c b/tools/libxc/xc_csched.c
> >> >> index 390c645..5a2bdf4 100644
> >> >> --- a/tools/libxc/xc_csched.c
> >> >> +++ b/tools/libxc/xc_csched.c
> >> >> @@ -36,7 +36,7 @@ xc_sched_credit_domain_set(
> >> >>      domctl.domain = (domid_t) domid;
> >> >>      domctl.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT;
> >> >>      domctl.u.scheduler_op.cmd = XEN_DOMCTL_SCHEDOP_putinfo;
> >> >> -    domctl.u.scheduler_op.u.credit = *sdom;
> >> >> +    domctl.u.scheduler_op.u.d.credit = *sdom;
> >> >
> >> > I don't see any change to any types in this series, which makes me
> >> > suspect it is in another patch and that bisectability is therefore not
> >> > maintained through the series. Each patch in the series needs to build
> >> > when they are applied one by one.
> >> >
> >> > This probably means that at to at least some degree hypercall interface
> >> > changes need to be done in the same time as the libxc adjustments. You
> >> > can still keep the _new_ functionality in a separate patch of course (if
> >> > that makes sense in this case).
> >>
> >> Because both per-domain and per-vcpu parameters are now unioned in
> >> struct xen_domctl_scheduler_op, we need to specify per-domain or
> >> per-vcpu when using domctl.u.scheduler_op.u (.d means per-domain, .v
> >> means per-vcpu). This change also happens to the XEN_DOMCTL_SCHEDOP_*
> >> handlers (of all schedulers), where the domctl.u.scheduler_op.u.* is
> >> passed to.
> >
> > I understand the interface change, but the problem is that the interface
> > change and the change ot the users of that interface seem to be in
> > different patches, which breaks bisectability.
> >
> > Does this series compile and work at every step?
> >
> > i.e. the following combinations of patches from this 4 patch series all
> > need to build and work successfully:
> >
> > Patch #1
> > Patch #1+#2
> > Patch #1+#2+#3
> > Patch #1+#2+#3+#4
> >
> > Is that the case?
> 
> I see your point. Do you mean the change of struct
> xen_domctl_scheduler_op, the change of XEN_DOMCTL_SCHEDOP_* handlers
> (in xen) and the change of libxc (just shown above) should be in the
> same patch? Should the title of that patch be something like
> "xen+libxc: enable per-vcpu parameter settings for RTDS scheduler" ?

Ah I said, you should be able to do the nop interface change in one
patch and then add the bindings for the new scheduler in a separate one.

Ian.
> 
> Chong
> >
> > Ian.
> >
> 
> 
> 



_______________________________________________
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®.