xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* About the credit2 scheduler
@ 2010-02-16 19:23 Jia Rao
  2010-02-17 12:14 ` George Dunlap
  0 siblings, 1 reply; 2+ messages in thread
From: Jia Rao @ 2010-02-16 19:23 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 428 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 526 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: About the credit2 scheduler
  2010-02-16 19:23 About the credit2 scheduler Jia Rao
@ 2010-02-17 12:14 ` George Dunlap
  0 siblings, 0 replies; 2+ messages in thread
From: George Dunlap @ 2010-02-17 12:14 UTC (permalink / raw)
  To: Jia Rao; +Cc: xen-devel

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@gmail.com> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-02-17 12:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-16 19:23 About the credit2 scheduler Jia Rao
2010-02-17 12:14 ` George Dunlap

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).