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

[Dario Faggioli <dario.faggioli@citrix.com>]

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

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

Other schedulers does not have similar knobs...yet. When/I case they
will, I expect the tweaks to be rather specific, and hence different
from the one offered by Credit (with, maybe, the exception of Credit2),
so it would not be too bad to have sched_rtds_params, or
sched_credit2_params as new and independent structs. In any case, this
is completely orthogonal to this discussion, IMO.

> 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 ) 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, if someone tries to use it with one
of the others, we can return the usual whatever_NOTSUP_whatever.

Regards,
Dario

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

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

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