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: 3124 bytes --]

On Thu, 2012-05-24 at 10:13 +0100, Ian Campbell wrote:
> 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. 
>
Yes, you're thinking right. Unfortunately, besides starting to
participate to that thread, I was off when consensus on that particular
aspect was reached. After that, I decided it is no such a big deal that
would worth a rewrite of the whole thing per-se, but if we are rewriting
it anyway, well... :-)

> I'm happy to
> go with whichever you guys think is best (which seems to be leaning
> toward separate structs?).
> 
I am definitely leaning toward that, but of course it's George's opinion
the one that we should care most.

> > > 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.
> 
That appears right to me, yes.

> 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?
> 
To me, definitely.

> > 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.
> 
Yes, let's just put what xm has together for now, we can add all the
other stuff later.

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