From: NISHIGUCHI Naoki <nisiguti@jp.fujitsu.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>,
xen-devel@lists.xensource.com
Cc: Ian.Pratt@eu.citrix.com, disheng.su@intel.com,
Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: [RFC][PATCH] scheduler: credit scheduler for client virtualization
Date: Fri, 05 Dec 2008 12:17:36 +0900 [thread overview]
Message-ID: <49389D50.60309@jp.fujitsu.com> (raw)
In-Reply-To: <de76405a0812040437m1bd8bfb1vdcc0307a1b26d736@mail.gmail.com>
Thanks for your information.
George Dunlap wrote:
> There was a paper earlier this year about scheduling and I/O performance:
> http://www.cs.rice.edu/CS/Architecture/docs/ongaro-vee08.pdf
>
> One of the things he noted was that if a driver domain is accepting
> network packets for multiple VMs, we sometimes get the following
> pattern:
> * driver domain wakes up, starts processing packets. Because it's in
> "over", it doesn't get boosted.
> * Passes a packet to VM 1, waking it up. It runs in "boost",
> preempting the (now lower-priority) driver domain.
> * Other packets (possibly even for VM 1) sit in the driver domain's
> queue, waiting for it to get cpu time.
I don't read the paper yet, but I think our approach is effective in
this problem.
However, if driver domain consumes cpu time too much, we couldn't
prevent it from becoming "over" priority. Otherwise, we could keep it
with "under" or "boost" priority.
> Their tests, for 3 networking guests and 3 cpu-intensive guests,
> showed a 40% degradation in performance due to this problem. While
> we're thinking about the scheduler, it might be worth seeing if we can
> solve this.
Firstly, I'd like to read the paper.
Regards,
Naoki Nishiguchi
next prev parent reply other threads:[~2008-12-05 3:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-03 8:54 [RFC][PATCH] scheduler: credit scheduler for client virtualization NISHIGUCHI Naoki
2008-12-03 9:16 ` Keir Fraser
2008-12-03 12:46 ` George Dunlap
2008-12-04 7:51 ` NISHIGUCHI Naoki
2008-12-04 12:21 ` George Dunlap
2008-12-04 12:37 ` George Dunlap
2008-12-05 3:17 ` NISHIGUCHI Naoki [this message]
2008-12-18 2:49 ` NISHIGUCHI Naoki
2008-12-18 10:21 ` George Dunlap
2008-12-05 2:47 ` NISHIGUCHI Naoki
2008-12-05 11:37 ` George Dunlap
2008-12-08 8:37 ` NISHIGUCHI Naoki
2008-12-04 7:45 ` NISHIGUCHI Naoki
[not found] ` <de76405a0901191232k19d910d5o77160fa5ee7bf06c@mail.gmail.com>
[not found] ` <de76405a0901191257p3b45304fi538d040b5634de23@mail.gmail.com>
[not found] ` <49768FDB.60609@jp.fujitsu.com>
2009-01-21 10:35 ` George Dunlap
2009-01-22 6:15 ` NISHIGUCHI Naoki
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=49389D50.60309@jp.fujitsu.com \
--to=nisiguti@jp.fujitsu.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=Ian.Pratt@eu.citrix.com \
--cc=disheng.su@intel.com \
--cc=keir.fraser@eu.citrix.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.