[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On mer, 2014-09-03 at 22:11 -0400, Meng Xu wrote:


> âSo let's first settle down the approach of setting/getting vcpus,
> (either one vcpu at a time or all batched vcpus.)â
> 
> 
> âWhat do you guys think about the approach of setting/getting vcpus?
> which approach do you prefer? Can we vote for it? (or maybe there
> exist some other ways to reach agreement? :-))â
> 
I'm not a fan of voting for this kind of things. :-)

I think we were close to nail it down in previous messages within this
thread. George said, in
<CAFLBxZaV9kUtc0=Ew3yO0BvR6EvLsHjK2pEOj6yB4eFpwG8big@xxxxxxxxxxxxxx>

 <<I guess the real question is how often we expect to be updating the
   parameters of a single vcpu, vs just setting all of the parameters
   (e.g., during domain creation).

   If we expect a lot of tweaking from user-space tools, then we should
   go with 3.  If we expect people to set parameters and then leave them
   alone, we should go with 1.>>

(where 3 is the array with a variable number of elements, i.e., only
relative to the affected vcpus, and 1 is the full array, with 0-s [or
whatever else] for 'don't touch this')

It's hard to be sure, but I'm leaning toward the full array (so 1, in
Meng's list in that email). In fact, I expect parameters to be set for
all the vcpus at, or immediately after, domain creation and, if
something has to change at some point, it's quite likely that it will
involve most (if not all) the vcpus (possibly, to different params, of
course). I also do not expect for that to happen too frequently.

1 also looks to me, although potentially inefficient, rather easier to
use and implement. E.g., immagine a toolstack --different from xl (and
perhaps even different than libxl)-- which has to live in a Dom0 with
limited support for dynamic memory allocations (are we thinking embedded
or not :-P). With 1, it can just prepare a static array a go with it,
while 3 may cause problems.

So, yes, I think I'd go for 1.

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: signature.asc
Description: This is a digitally signed message part

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.