[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |