| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] credit based scheduler
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
|
|
|
| |
|
Home