Re: [PATCH v1 1/4] xen: add real time scheduler rt

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

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

On mer, 2014-09-03 at 15:20 +0100, George Dunlap wrote:
> So if I'm reading this right, you set the information for vcpus one
> vcpu at a time, but you want to read the whole lot out all at once?
> 
> I don't like the inconsistency.  It would be better if you did the
> same thing each direction:  Either pass in an array with info about
> the vcpus, or just read the vcpu information one-by-one.
> 
I agree. One by one (in both reading and writing direction) was what I
suggested, but others (I think it was Andrew) pointed out that, when
hypercall are involved, batching is always a good thing. And in fact
(although maybe not in hot paths) it's quite likely that one wants to
retrieve the parameters for all the vcpus (e.g., it is like that as far
as xl is concerned), so that's why, IIRC, Meng went for the batching
approach.

I also continue to think that, in the case of this scheduler, a good API
would include both calls to set and get one vcpu at a time *AND* calls
to set and get all of them.

I'm fine with this version only having one of the two alternatives (and
about adding the other one later), but I agree with George it should be
consistent.

If we like batching, then batching it is, but I think in that case we
need to think about one change the parameters of only one vcpu (perhaps
treat budget=0 && period=0 in the i-eth element of the array as 'don't
touch vcpu #i"?).

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- 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