Re: [Xen-devel] About the credit2 scheduler

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

The problem with the credit scheduler isn't necessarily that it uses
credits.  The big problem is how it deals with VMs that don't use all
their credits; they end up flipping back and forth between highest and
lowest priorities.  (See my Xen Summit Asia presentation for more
information: http://www.xen.org/xensummit/xensummit_fall_2009.html,
under "Topics in Xen") The secondary problem is the fact that it
divides everyone up into 3 priorities (BOOST, UNDER, and OVER) and
schedules things round-robin, with 30ms timeslices, within those
priorities.  Round-robin is known to discriminate against workloads
that yield often (as latency-sensitive workloads tend to do) in favor
of workloads that use up their full timeslice (as cpu-burn workloads
tend to do).

My new scheduler, credit2, still uses credits; but the way it deals
with VMs that it deals with VMs that don't use all their credits is
completely different.  Furthermore, within some set limits, it tries
to run VMs that have the highest credit, rather than scheduling
round-robin.

I looked at the Linux scheduler, and although they do have a basic
concept of "credits", I'm not sure how they deal with VMs that don't
use all their credits.  Furthermore, VMs have different scheduling
needs than processes: VMs typically have their own interrupts, whereas
in Linux, latency-sensitive things (like filling audio buffers or
doing TCP ACKs) tends to happen in the kernel, which is higher
priority than all processes.

 -George

On Tue, Feb 16, 2010 at 7:23 PM, Jia Rao <rickenrao@xxxxxxxxx> wrote:
> Hi All,
> I am curious that how is the credit scheduler compared to the linux default
> CPU scheduler ?
> They look quite similar. Do the problems in the credit scheduler also exist
> in Linux CPU scheduler?
> What I understand is that, virtual machine monitors have a higher
> requirement in "fair sharing" than Linux. Therefore, we need credit-based
> scheduling which can possibly cause problems for latency sensitive
> workloads.
> Thanks
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>

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