Re: [PATCH 3 of 3] libxl: make it possible to explicitly specify default sched params

[Dario Faggioli <raistlin@linux.it>]

[-- Attachment #1.1: Type: text/plain, Size: 3467 bytes --]

On Wed, 2012-05-23 at 20:28 +0100, George Dunlap wrote: 
> Overall the idea of the patch looks good.  There's just the thing
> about shoving all the various schedulers' parameters into one struct.
>
Yep, I really don't like that either.

> One fall-out from it is that if you specify weight in your config file
> (or during domain creation), it will set the weight for credit or
> credit2, but use the defaults for sedf.  This might be nice; but we're
> implicitly baking in an assumption that parameters with the same name
> have to have roughly similar meanings across all schedulers.
> Furthermore, if someone sets a "cap" in the config file, for example,
> but starts the VM in a pool running credit2, should we really just
> silently ignore it, or should we alert the user in some way?
> 
I agree... Some mechanism for providing the user at least with a warning
would be useful.

> In any case, this patch only takes things half-way.  If we're really
> going to have One Struct to Rule Them All, we don't need different
> domain_set/domain_get functions for the different schedulers -- we
> just need a libxl_sched_domain_get(), which will both figure out what
> scheduler the domain is running, and fill in the appropriate
> parameters, and a libxl_sched_domain_set(), which will check to see
> that you've asked for the right scheduler (or marked "unknown" if you
> aren't afraid), and set what it can set.  
>
According to my personal taste, that would be quite ugly, not to mention
that every time we might be adding/removing/modifying a scheduler, we
would need to update this Frankenstein-struct, potentially affecting all
the other ones... :-(

> I'm not really sure which way I think is best.  I can see the
> advantage of not having to know which scheduler is actually running,
> but I'm a bit wary of baking in assumptions about the equivalence of
> parameters; it seems like it could lead to some nasty surprises.
> 
I agree again: the fact that, right now, _almost_ all the existing
schedulers have a parameter called weight with _almost_ the same meaning
shouldn't allow us to assume that to be true now and forever.

> But I think whichever way we choose, we should take it to its logical
> conclusion.  Which in the "One Struct" way, would mean having a single
> domain_get/domain_set function, and in the "separate struct" way would
> probably mean specifying the scheduler -- i.e., "credit_weight",
> "credit2_weight" or something like that.  (Obviously we need xm
> compatibility, but we can throw a warning to encourage people to
> change their config files.)	
> 
For what it counts, I'm all for option #2, i.e., each scheduler with its
own struct, set of helper functions, xl sub-command, etc. Something like
'credit.cap = XX', 'credit2.weight = XX' or 'sedf.period = XXX' would be
nice, for discriminating them in the config file. It'd remain to decide
what to do with things like 'weight = XX', which we need to support for
backward compatibility, but I guess almost anything is fine, provided we
warn the user about what's happening and ask him to update the syntax.

Just my 2 cents. :-)

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel