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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2012-05-23 at 22:19 +0100, Dario Faggioli wrote:
> 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.

I think we reached to opposite conclusion when Deiter implemented the
sched params support, but I don't really mind either way. I'm happy to
go with whichever you guys think is best (which seems to be leaning
toward separate structs?).

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

So xl should query the scheduler for the pool which has been specified
in the config and parse the appropriate options? That seems doable.

At the libxl level I think this would end up being a KeyedUnion in the
build info, selecting the appropriate per-sched params struct. Does that
sound reasonable?

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

That all sounds fine, but not for 4.2 IMHO.

Ian.

> 
> Just my 2 cents. :-)
> 
> Regards,
> Dario
> 



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