Re: [RFC] [Design] Better XL support of RTDS scheduler for Xen 4.6

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-02-24 at 10:52 +0000, Dario Faggioli wrote:
> On Tue, 2015-02-24 at 10:37 +0000, Ian Campbell wrote:
> > On Mon, 2015-02-23 at 22:58 -0500, Meng Xu wrote:
> > > I'm not sure if other schedulers need such functionality right now,
> > > because the credit2 scheduler account for the credit based on each
> > > domain instead of each VCPU. But if the scheduler will consider the
> > > vcpu-level credit/budget accounting, this could be helpful.
> > 
> > We should take it as given that some other scheduler will want
> > vcpu-level parameters in the future and decide now how we want that
> > interface to look across multiple schedulers now,
> >
> +1
> 
> > with the big question
> > I suppose being a large union struct vs individual structs (and perhaps
> > a KeyedUnion).
> > 
> Indeed.
> 
> > At the domain level param level we have libxl_domain_sched_params in
> > libxl_domain_build_info and via libxl_domain_sched_params_set/get.
> > 
> > We also have libxl_sched_credit_params and
> > libxl_sched_credit_params_get/set for the credit scheduler, but not for
> > other scheduler types.
> > 
> > I don't recall how we ended up with both, are the credit ones
> > deprecated/legacy and the combined one the One True Way or the other way
> > around?
> > 
> sched_credit_params are system level parameters, i.e., they apply to an
> instance of the credit scheduler as a whole (so, to all the host or to a
> cpupool).

Ah, ok, then yes these can be ignored for the purposes of this
conversation I think.

This means that the current interface is the one-big-struct type.

> > In any case, we should decide what we want for both per-domain and
> > per-vcpu parameters, with one eye on the libxl API guarantees, and try
> > and have them at least be somewhat consistent.
> > 
> Exactly. My opinion would be to leave the per-domain interface alone as
> it is (we probably don't have much alternatives to this, BTW, due to API
> stability! :-D )

We do have the option of introducing a new/better interface so long as
the old one also continues working.

>  and introduce a new (set of) API(s) for per-vcpu level
> parameters.

> The former will still be preferred/used by the schedulers that does not
> support different per-vcpu params, or by all the schedulers, if they
> want to set all the params for all the vcpus to the same values (e.g.,
> default values at domain creation time, if nothing is specified in the
> config file).
> 
> The latter would be, of course, used by the schedulers that support
> different per-vcpu parameters and,

You seem to be implying ("still be preferred") that there will be some
sort of either/or choice here between the per-domain and per-vcpu
interfaces.

Surely a scheduler can have both domain-wide and per-vcpu parameters and
a given scheduler might implement either or both as it needs.

>  if someone tries to use it with one
> of the others, we can return the usual whatever_NOTSUP_whatever.

Obviously.

Ian.