[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Questions regarding Xen Credit Scheduler


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: Zhiyuan Shao <zyshao.maillist@xxxxxxxxx>
  • Date: Fri, 17 Dec 2010 22:25:53 +0800
  • Delivery-date: Fri, 17 Dec 2010 06:26:58 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=k7g5NG3TSmLM0iq3tsZ7H+xeEP6iMBNCAHhxbSSTSlDb9Tnjotf+uXDDjTraFXNRXd Z7o7DWNvi5jlfOhSlPD295pGeE4hWru/KXYMlIww954mlmlwDOQQL8tIrQi/abdiFF2S SZzVAQ/i32VFLUSOUfb1KlaLg57N534vj+/mY=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

In your case, I think, you can try Boost-Credit. Your I/O intensive domain will benefit for that.

Best,
Zhiyuan

On 07/09/2010 05:14 AM, Gaurav Dhiman wrote:
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

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


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.