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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Feb 24, 2015 at 10:58:06AM +0000, Dario Faggioli wrote:
> On Mon, 2015-02-23 at 22:58 -0500, Meng Xu wrote:
> > 2015-02-23 10:57 GMT-05:00 Wei Liu <wei.liu2@xxxxxxxxxx>:
> 
> > >> In order to implement the set function, which set the parameters of
> > >> one specific VCPU of a domain, we have two different approaches to
> > >> implement it:
> > >> Choice 1): When users set the parameters of k^th VCPUs of a domain,
> > >> which has x VCPUs in total, the toolstack passes "only" the modified
> > >> VCPUsâ information from userspace to hypervisor via hypercall;  So
> > >
> > > A new hypercall or existing hypercall?
> > 
> > We only need to change the current hypercall
> > (XEN_DOMCTL_SCHEDOP_setinfo) implementation:
> > 
> IMHO, it can be either way (add a new one or change the existing one). 
> 
> > >> Choice 2): When users set the parameters of k^th VCPUs of a domain,
> > >> which has x VCPUs in total, the toolstack will create an array with
> > >> length x and set the information (period, budget) of the k^th element
> > >> in the array. The other elements in the array are marked as 0. After
> > >> the toolstack bounce the array into the hypervisor, it will only set
> > >> the parameters of the k^th VCPU.
> > >>
> > >
> > > One thing to consider is when you have hundreds of cpus the overhead
> > > might be too big? What's the amount of data you need to pass down to
> > > hypervisor?
> > 
> > Suppose a domain have k VCPUs, each VCPU has info: period (uint32_t),
> > budget(uint32_t), and index(uint32_t); So each hypercall will pass k *
> > (3*8Bytes) to the hypervisor.
> > 
> Maybe I'm missing something but, if we pass the array, why do we need
> the index? Oh, and in case we need the index, it can well be smaller
> than 32 bits.
> 
> For Wei, we're talking about _v_cpus here (in your reply you're just
> saying 'cpus', so I'm not sure whether you were referring to _v_ or _p_
> cpus). If we have a guest with k > 100 vcpus, it's either:

Yes, I was talking about vcpus. AIUI the proposed hypercall is for
setting vcpu parameters. :-)

>  - pass a k ( > 100) element array down to Xen
>  - issue k ( > 100) hypercalls back to back
> 
> OTOH, if we have such a large guest, and we only want to change the
> params for one vcpu and we go for batching, we'd always have to pass the
> big array, with only one meaningful value.
> 
> Allow me to say that the more common use case for this scheduler would

The name of that hypercall XEN_DOMCTL_SCHEDOP_setinfo doesn't suggest it
is only used for this particular scheduler.

> not include guests that big. Also, I expect most of the users wanting to
> set the parameters of the various vcpus all together, and, if not once
> and for all, at least quite rarely, rather than tweaking the values
> every now and then.
> 

Right. This makes sense. Listing some common use cases can help us
establish expectation of a certain interface, so ...

> Then, of course, users will do the weirdest things, so we really should

when users do weird things we can say "it's not supposed to work like
that, your expectation is wrong, blah blah blah".

> consider the overhead, but I thought it would be worth to at least
> mention this.
> 

That would be good.

Wei.

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