| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] credit based scheduler
On Wed, Jun 21, 2006 at 03:26:48PM +0100, Steven Hand wrote:
> > Is there a plan to make the credit based scheduler the default
> > scheduler? Also, is there any performance data available for this
> > scheduler?
>
> It has been made the default from yesterday (xen-unstable cset
> 10459:a31f3bff4f76) so that we can get more widespread usage
> before calling 3.0.3
>
> Performance is "pretty good", and certainly fixes some of the
> previous behaviour with sedf, but I don't have any specific
> numbers to hand. Emmanuel may have more more details?
I responded to a similar enquiry from Anthony a few weeks ago:
http://lists.xensource.com/archives/html/xen-devel/2006-05/msg01346.html
Short summary: I've seen improvements over the other schedulers
with everything I have tried. Let's not forget though: Raw
performance numbers on various benchmarks are useful. But the
scheduler's responsabilities also include defining and enforcing
fairness among all active guests.
I'll add the following about latency and throughput philosophy:
The credit scheduler is an SMP CPU scheduler. It is designed such
that no physical CPU will ever idle if there is a waiting
runnable VCPU on the host. We call this being work conserving.
This is in contrast to other schedulers which are UP CPU
schedulers glued together with higher level tools to migrate
VCPUs between physical CPUs.
For example, consider an 4CPU server hosting 32 concurrent web
server guests. Being work conserving accross all physical CPUs,
the credit scheduler is going to give you a lot more total system
throughput (more web server guests per physical host) and better
per-guest response times (HTTP ops/sec) too.
Additionally, the credit scheduler ensures that all guests
throughout the system get a fair share of all host CPU resources:
3 active UP guests on a 2CPU host each get 33% of the total CPU
available; The credit scheduler takes care of migrating guest
VCPUs across physical CPUs to achieve this transparently. If you
are in the business of consolidating servers onto one physical
box, this is pretty important.
Finally, there is a question of when to preempt a running domain
to run another runnable one. The credit scheduler runs VCPUs in
30millisecond time-slices by default (That's about the time it
takes the human eye to focus or notice queueing latency). A VCPU
being woken up will preempt the time-slice of a running VCPU only
if the latter has already run more than its fair share and the
former has not. A VCPU is assigned a fair share of the system if
it is "active". To be considered "active", a VCPU must be
runnable at least once in the time it takes it to fairly "earn"
one time-slice.
Consider two competing VCPUs on a UP host: A is spinning. B is
doing I/O (it's sleeps and wakes up much more often than every
30 milliseconds). Both A and B are considered "active". If B is
not able to consume its fair share of the CPU because it is
constantly waiting for I/O, it will at least preempt A every time
it becomes runnable. B gets good service in the way of short
latencies from being runnable to actually running. On the other
hand if B only rarely does an I/O operation but consumes the CPU
otherwise, it will not always preempt other running VCPUs when it
wakes up. That would be "unfair" to the other VCPUs. The credit
scheduler uses preemption to provide good service to latency
sensitive guests, but in a fair way: I/O bound VCPUs will not
starve out compute bound ones by constantly preempting them.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home