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

On Mon, 2015-02-23 at 23:15 -0500, Meng Xu wrote:
> 2015-02-23 12:27 GMT-05:00 Dario Faggioli <dario.faggioli@citrix.com>:

> > That of course does not mean that we the API, at all levels, need to
> > always deal with all vcpus. As you know very well, there is the hcall
> > interface, where we said we want to batch; then there is the libxc
> > interface, which can well diverge, but it's usually better map quite
> > closely to the hcall one; and then there is libxl, on top of libxl, and
> > things can be significantly different here.
> >
> > So, I think your design proposal/code should explicitly state what the
> > plan is at each level.
> 
> I agree.
> In my mind, my plan is to have all levels batching the request, from
> xl to libxl to libxc to rt_dom_cntl() in sched_rt.c.
> 
xc and Xen, I agree. libxl, I'm not sure (a few more words on this
below), xl, it may make sense, but depending how you support specifying
the budget for multiple vcpus.

> > If we batch for get, I think we should batch for set. As I said, I
> > personally see some value in an interface allowing setting all the
> > parameters of all the vcpus at the same time. In fact, this is probably
> > better, even as far as real-time theory is concerned: as I'm sure you
> > know better than me, parameter changing can be tricky for the algorithm,
> > so it's probably better to encourage the user to change the params all
> > together, synchronously, rather than having to deal with a stream of
> > adjustments scattered in time.
> >
> > So, my opinion, choice 2).
> 
> OK. Agree! :-P
> I think this is also the reason why libxl and xl should use batch as
> well, for consistence?
> 
Not really. Consistency is important, but now between completely
different and independent things. Hypercalls, libxc calls, the libxl API
and xl commands have very different users, and the interface should be,
at each layer, the best one for the layer's users.

> > If I can add something, the big challenge here is how to make the
> > interfaces good and homogeneous enough with what we already have in
> > place for other schedulers. I really suggest you to address this too in
> > this design conversation and/or in RFC/code.
> 
> Actually, there is a basic question:
> Should we back support the existing xl tool for RTDS? Right now, we
> assume all VCPU of the same domain have the same parameter and the
> toolstack (xl, libxl, libxc and rt_dom_cntl()) are implemented based
> on such assumption.
>
Xen (so the hypercall), libxc and xl commands are not stable interfaces.
Add to this the fact that this feature is marked as experimental. So, in
in general, I would say that there's no need for ensuring backward
compatibility for these components. That being said, wrt to Xen and
libxc, whether you want to add a new hypercall and a (well, two) new xc
call, or you want to modify the existing ones, it's up to you and to the
hypervisor and tools maintainers' opinion.

I don't think it would be terrible to leave an interface to set the
parameters of all vcpus of the domain alone, as we have for all the
other schedulers, and add hcalls and xc calls to set per-vcpu values.
Actually, if we design this well, it could be useful in future for other
schedulers, or if existent schedulers want to support different per-vcpu
parameters.

OTOH, libxl API is stable, so we must not change the look of the
behavior of calls introduced in a release. As said above, I think it is
actually a good thing to continue having a mechanism for setting the
parameters of all the vcpus of the domain at the same time, so I will
introduce per-vcpu parametes support as an entirely new API.

> If we have implemented the vcpu-level parameter control, it will be a
> superset of the current 'xl sched-rtds'. Back-supporting the current
> xl tool for RTDS scheduler (only) will just make the logic a bit more
> complex.
> I'm not sure if back-supporting for the experimental feature is a must?
>
In xl, it's again not "a must". However, I would not kill the current
logic. In fact, how about the following:

# xl sched-rtds -d 4 -p 10000 -b 5000
 |
 --->  sets all the vcpus of domain 4 to 5000/10000

# xl sched-rtds -d 3 -v 2 -p 5000 -b 2000
 |
 ---> set vcpu 2 of domain 4 to 2000/5000

# xl sched-rtds -d 2 -v 0 -p 10000 -b 1000 -v 1 -p 5000 -b 2500
 |
 ---> set vcpu 0 of domain 2 to 1000/10000 and vcpu 1 of
      domain 2 to 2500/5000

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