[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC Patch 1/3] Remove sedf extra, weight, and latency parameter support.
On ven, 2014-03-14 at 15:13 -0400, Nathan Studer wrote: > From: Nathan Studer <nate.studer@xxxxxxxxxxxxxxx> > > Remove sedf extra, weight, and latency parameters from the scheduler's adjust > function. Also remove the support for these parameters from the xl toolstack. > So, from the code point of view, this looks okay, as the rest of the series. My only concern is that, at least extratime and weight, we may need in future, so we'll be removing them here, to reintroduce them in a bit. The reason why I think we could need them back is that, although I concur that work conserving-ness is less important now that there are schedulers much more suitable for general purpose workloads (credit and credit2), it, in my experience, could come handy in real-time scenarios too. However, what the best interface is will only become clear in a while, after the re-design and the re-implementation. Therefore, my take on this would be, let's remove everything, as you're doing in here, and perhaps add what we will end up needing when we will need it/them... which would mean an Ack, from my side, on this patch too. However, since we're discussing interfaces, I'd love to hear what others think. Of course, even if we take the 'kill everything [for now]' route, there's the matter of libxl API stability. So, when it'll come to this, and other libxl API related changes: > index 7d3a62b..1265a73 > --- a/tools/libxl/libxl_types.idl > +++ b/tools/libxl/libxl_types.idl > @@ -291,8 +291,6 @@ libxl_domain_sched_params = Struct("domain_sched_params",[ > ("cap", integer, {'init_val': > 'LIBXL_DOMAIN_SCHED_PARAM_CAP_DEFAULT'}), > ("period", integer, {'init_val': > 'LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT'}), > ("slice", integer, {'init_val': > 'LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT'}), > - ("latency", integer, {'init_val': > 'LIBXL_DOMAIN_SCHED_PARAM_LATENCY_DEFAULT'}), > - ("extratime", integer, {'init_val': > 'LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT'}), > ]) > We'll need the macro tricks to make it safe. For adding fields we usually specify a suitable LIBXL_HAV_FOO symbol... I guess in this case LIBXL_API_VERSION is more suitable? If yes, I'm not sure how it would be best use to affect the actual struct definition, as it originates from the IDL parser... 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |