xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jia Rao <rickenrao@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: About the credit2 scheduler
Date: Wed, 17 Feb 2010 12:14:15 +0000	[thread overview]
Message-ID: <de76405a1002170414k36d9db06x6c244bb1d6876337@mail.gmail.com> (raw)
In-Reply-To: <994429491002161123u4282ftb407f1d700fac36b@mail.gmail.com>

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
>
>

      reply	other threads:[~2010-02-17 12:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-16 19:23 About the credit2 scheduler Jia Rao
2010-02-17 12:14 ` George Dunlap [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=de76405a1002170414k36d9db06x6c244bb1d6876337@mail.gmail.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=rickenrao@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).