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 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)
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xenemail@example.com https://lists.xen.org/xen-devel