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

On Tue, 2015-02-24 at 11:06 +0000, Ian Campbell wrote:
> On Tue, 2015-02-24 at 10:52 +0000, Dario Faggioli wrote:

> > 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.
> 
I was implying some kind of either/or logic, yes, although not in a
static and mutually exclusive way.

> Surely a scheduler can have both domain-wide and per-vcpu parameters and
> a given scheduler might implement either or both as it needs.
>
Oh, I see. well, of course, if there are parameters that are clearly
domain-wide and others that are clearly per-vcpu, they should live in
their respective structs, and the scheduler should implement things as
per its needs.

The problem is whether or not we allow overlap, i.e., whether the same
parameters can live in both interfaces, and what is the semantic of
that.

Let's take RTDS as an example. budget and period make sense at the vcpu
level so, as soon as we introduce the API for per-vcpu params, they
should live there. But then what about the budget and period field we
have in libxl_domain_sched_params? What's the meaning of them?

Semantically speaking, they just should be killed. OTOH, what I was
suggesting was this: if one calls libxl_domain_sched_params_set(), which
takes a libxl_domain_sched_params, the budget and priod there will be
interpreted as "for the whole domain", and applied to all the domain's
vcpus. It's in this sense that I see it an either/or:
 - at domain creation time, if the user does not say anything we'll use
   the domain-wide API for setting a default budget and period for all
   the vcpus.
 - if the user does say something in the config file (once this will be
   possible), or upon request, via the proper xl command, to modify the
   parameters of vcpu X, we'll use the vcpu-wide API.

Of course this applies to parameters that are part of both
structs/interfaces, which is something I was thinking to allow... were
you?

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