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:
> [...]
pgpRVqVzQ2Ery.pgp
Description: PGP signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home