From: Gaurav Dhiman <dimanuec@gmail.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: Questions regarding Xen Credit Scheduler
Date: Thu, 8 Jul 2010 14:14:12 -0700 [thread overview]
Message-ID: <AANLkTiloe7jgMO49i72sF0MDFmuHJJeysEBb0oLVNono@mail.gmail.com> (raw)
Hi All,
I am using Xen 3.3.2 for some of my experiments, and have been
consistently observing some sub-optimal results in our experiments
with latency sensitive I/O intensive and compute bound VMs running
together on a physical machine. We are observing latency issues in
cases with enough CPU resources available for both the VMs to co-exist
well, even if we give much higher weight to the latency sensitive VM.
I suspect it is due to the way the Xen credit scheduler works. In this
context, I have some questions regarding the scheduler:
1) In the sched_acct function, the credit cap is set to 300, enough to
survive one time slice. But if some VCPU crosses that cap, it is set
to 0, and marked inactive. Why is there no concept of a ceiling (like
that of a floor for the VCPUs going over the credit line), i.e. why is
it not set to 300? Is there some fundamental reason for setting it to
0? I believe this is resulting in a lot of times when our latency
sensitive VCPUs have to wait for maybe a time slice, when they can
immediately run. This might happen if they run with BOOST priority and
get interrupted by a timer tick, which takes that priority away.
2) Why is the runq sorted by just priority (which is very coarse
grained: BOOST, UNDER and OVER), and not the credit? This can result
in VCPUs with higher credit getting starved for CPU if we have batch
and latency sensitive VCPUs in the system.
3) Is there some patch, which makes the current credit scheduler
fairer to the latency sensitive VCPUs? I see that the sched_credit2
scheduler addresses these issues, but right now it has just one global
runq and no load balancing features.
Any advice/inputs here will be extremely valuable!
Thanks in advance,
-Gaurav
next reply other threads:[~2010-07-08 21:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-08 21:14 Gaurav Dhiman [this message]
2010-07-09 12:13 ` Questions regarding Xen Credit Scheduler George Dunlap
2010-07-10 9:21 ` Gaurav Dhiman
2010-07-12 11:05 ` George Dunlap
2010-07-16 0:41 ` Gaurav Dhiman
2010-07-16 9:13 ` George Dunlap
2010-07-16 11:04 ` George Dunlap
2010-12-17 14:23 ` Does Xen-4.0 + pvops kernel still supports PV guest? Zhiyuan Shao
2010-12-17 14:36 ` Ian Campbell
2010-12-17 14:51 ` Zhiyuan Shao
2010-12-17 15:07 ` Ian Campbell
2010-12-17 14:25 ` Questions regarding Xen Credit Scheduler Zhiyuan Shao
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=AANLkTiloe7jgMO49i72sF0MDFmuHJJeysEBb0oLVNono@mail.gmail.com \
--to=dimanuec@gmail.com \
--cc=george.dunlap@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 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).