Re: [Xen-devel] credit based scheduler

[Emmanuel Ackaouy <ack@xxxxxxxxxxxxx>]

On Thu, Jun 22, 2006 at 12:26:02PM +0200, Molle Bestefich wrote:
> To explain myself a bit more, I was wondering whether the scheduler
> conceptually can be said to work a little like this (VCPUs mapped to
> CPUs in a "ring-fashion"):
> 
> (VCPUs = A, B, C)
> 
> Time     CPU1  CPU2
> 0ms      A     B
> 30ms     B     C
> 60ms     C     A
> 90ms     A     B
> 120ms    B     C
> ...etc...
> 
> This would give 30ms slices with a time-to-wait for scheduling of 30ms.

Here, you're moving something that is already running from
one CPU to another. The credit scheduler won't do this. It
moves something that is on a CPU's runq but hasn't had a
chance to run on that CPU.

> Or perhaps more like this:
> Time     CPU1  CPU2
> 0ms      A     B
> 30ms     A     C
> 60ms     B     C
> 90ms     B     A
> 120ms    C     A
> ...etc...
> 
> Which gives 60ms slices (warmer cache, yummi) but still with a
> time-to-wait for scheduling of 30ms.
> 
> The latter obviously being a better algorithm, cache-wise...

The credit scheduler behaves like this latter example:

Basically, once a VCPU has ran two consecutive time-slices,
its physical CPU goes and looks for a VCPU on the other CPU's
runq which hasn't yet ran its fair share. It's the very act
of running two consecutive time-slices on a PCPU while two
other VCPUs are time-slicing on the other PCPU which causes
the fair share imbalance which then causes the migration.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel