[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

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

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': 
>      ("period",       integer, {'init_val': 
>      ("slice",        integer, {'init_val': 
> -    ("latency",      integer, {'init_val': 
> -    ("extratime",    integer, {'init_val': 
>      ])
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...


<<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



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