[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Credit scheduler and latencies
On Thu, 14 Dec 2006 19:10:53 +0000 Emmanuel Ackaouy <ack@xxxxxxxxxxxxx> wrote: > Hi Milan, > > This is interesting data. Glad that it is useful. > I'm quite surprised that you managed to get one of three > CPU hogs to get more than 33.3% of the CPU! This is not > expected behaviour. I'll look into it. Great. > It is however expected behaviour that once a VCPU consumes > its fair share of CPU resources, it will no longer preempt > others and will have to wait its turn for a time slice. > If we didn't do that, the VCPU in question could just hog > the CPU. Yes, I probably should have mentioned clearly that I read sth like that in the archives. > The way to increase the share a VCPU can use and still > preempt others when waking up is to up the fair share of > the domain in question to make sure that it's constantly > using less than its fair share of the CPU. But then, this > domain will have the ability to actually use that many > CPU resources. Yes, but see below... > The credit scheduler doesn't have a good mechanism to > guarantee a sub ms wake-to-run latency for VCPUs that it > must also restrict the CPU usage of. The assumption is > that if you require good wake-to-run latencies, then you > are not a CPU hog. This assumption may not be valid in > all workloads. I do not want to make this assumption in my case, as it can become false. (E.g. running a I/O-based-workload, and then logging in via SSH (usually short CPU hog) or doing some other work (like nice'd bzip2)) > Short of recompiling source, there is no currently no > way to change the default time slice I'm affraid. And if > you recompile, you're indeed exploring uncharted territory. Yes. I already read a part of it, but I don't know everything about the scheduler API and the credit scheduler in particular yet. Can you say whether it is possible / feasible to change the time slice / scheduler quantum to less than 10 ms (time between two 100-Hz-based timer interrupts)? I think I will try out 10 ms and then 1 ms in the next days. > [...] > > Are you trying to guarantee wake-to-run latencies for > one or more domains which also hog CPU resources if left > to run unchecked? Yes, this would be the ideal case. Good wake-to-run latencies and in general reliable CPU limiting at the same time. > In 3.0.4, you could try to use SEDF which basically seems > to run 1ms time slices. Last time I checked SEDF was 3.0.2. IIRC, I can assign fixed slices of CPU time to each domain, and I can specify whether each domain can consume extra CPU time. I *think* extra CPU time didn't work at back then. I guess I'll have a look at SEDF again too. > I can also add whatever mechanisms > you require to the credit scheduler but depending on what > is required, that may not happen for a while, and likely > not in 3.0.4. I guess that sth like allowing any domain to interrupt at any time and at the same time distributing CPU usage fairly doesn't quite fit in the current credit scheduler's concept..? I will tell you if I have more concrete ideas for the credit scheduler. > Cheers, > Emmanuel. Regards, Milan PS: I'm subscribed, so you can also send mail only to the list. > On Thu, Dec 14, 2006 at 06:24:43PM +0100, Milan Holz?pfel wrote: > [...] Attachment:
pgp_4S0SuiGGB.pgp _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |