This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Questions regarding Xen Credit Scheduler

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Questions regarding Xen Credit Scheduler
From: Gaurav Dhiman <dimanuec@xxxxxxxxx>
Date: Thu, 8 Jul 2010 14:14:12 -0700
Cc: george.dunlap@xxxxxxxxxxxxx
Delivery-date: Thu, 08 Jul 2010 14:14:49 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=0y/FYMB1DXerULRBR+ZG5q/2WBCM1qMNkGM7z6+uCBI=; b=W4AYrhndNsw0D/8vUGLdFQzUqyeVY/aLg2O+W2Fh22+7iiBGBU7J3S5TB5fdrQ6d33 45izvD1HVQyk9Ri4K/ZTl4voc/Sf6+2wTHGehahkz9JSB79T1oNJih2D/A+u1lBZVFob 0+I5ZBp97I5QtFcQ81xRZK0pHUQyY6GLB5Zsc=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=etvvRjlQPrQrLTF61BlbnI578JgpE+rrusKzU+2toES7lEJNTwLUQZdTyVkIVCwV6S 3HwYgWn9ohcSqqJN3YmLZ82toSi5mJ5fiiO/TFbtVEANphOiEI37hb5w310ShrvY5gow wS5ExduzHbNYvLstHrrr05RxgUBTgwAIDmtBA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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,

Xen-devel mailing list