On Tue, 2016-10-18 at 19:52 +0100, Juergen Schinker wrote:
> > On Tue, Oct 18, 2016 at 6:51 AM, Wei Liu <wei.l...@citrix.com>
> > wrote:
> > > 
> > Another thing is that the current RTDS scheduler will only allocate
> > the amount of resource to the VCPU you set.  Since you set period
> > and
> > budget to be 20000 and 8000, you only get 40% CPU resource. (We
> > won't
> > get more resource than you set under the current RTDS.)
> > 
> what is the min max?
Not sure what you mean, but I think the answer is that it's a max.

I.e., a vcpu will never get more than 8ms every 20ms, which means it
will never get more than 40% CPU time. But if it asks less than that,
it will (of course!) get less).

It can also be seen as a min, but that depends on the system
configuration. So far, there is nothing that prevents you to assign 40%
of CPU time to 10 vCPUs. This means you've allocated 400% CPUs. If you
have, say, only 2 CPUs, you're overbooking, and there's no way everyone
will get all of what they ask for.

How graceful the performance degradation is, I'll leave it to Meng (I
recall EDF does that in a very nice manner, but I can't remember
whether that is the case in the actual algorithm RTDS is based on).

But again, I'm not sure whether this is what you were asking.
> well I just wanted to test it and see how it performs and don't have
> a special need for this scheduler
Ah, ok. When doing such experiments, consider using cpupools. They come
in very handy, as you can dynamically assign a scheduler to a set of
CPUs, move domains there, and test and check whatever you want, without
having to reboot with different parameters, etc.

> except shutting up loudmouthes who say you can not assure
> min  resources to a domain :-)
Right, this is a very good purpose... Let us know if you need help on
it! :-P

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

Reply via email to