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

Re: [Xen-devel] Credit scheduler and latencies

  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: Milan Holzäpfel <listen@xxxxxxxx>
  • Date: Thu, 14 Dec 2006 20:35:30 +0100
  • Delivery-date: Thu, 14 Dec 2006 11:35:29 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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.


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


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
Description: PGP signature

Xen-devel mailing list



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