WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] The caculation of the credit in credit_scheduler

To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: [Xen-devel] The caculation of the credit in credit_scheduler
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Fri, 5 Nov 2010 15:06:21 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Delivery-date: Fri, 05 Nov 2010 00:07:24 -0700
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
Thread-index: Act8t/OXZ6bLDSZ9SFmoF+2ChyNA1Q==
Thread-topic: The caculation of the credit in credit_scheduler
When reading the credit scheduler code and doing experiment, I notice one thing 
interesting in current credit scheduler. For example, in following situation:

Hardware:
A powerful system with 64 CPUs.

Xen Environment:
Dom0 with 8 vCPU bound to CPU (0, 16~24)

3 HVM domain, all with 2 vCPUS, all bound as vcpu0->pcpu1, vcpu1->pcpu2. Among 
them, 2 are CPU intensive while 1 is I/O intensive.

The result shows that the I/O intensive domain will occupy more than 100% cpu, 
while the two cpu intensive domain each occupy 50%. 

IMHO it should be 66% for all domain.

The reason is how the credit is caculated. Although the 3 HVM domains is pinned 
to 2 PCPU and share the 2 CPUs, they will all get 2* 300 credit when credit 
account. That means the I/O intensive HVM domain will never be under credit, 
thus it will preempt the CPU intensive whenever it is boost (i.e. after I/O 
access to QEMU), and it is set to be TS_UNDER only at the tick time, and then, 
boost again.

I'm not sure if this is meaningful usage model and need fix, but I think it is 
helpful to show this to the list.

I didn't try credit2, so no idea if this will happen to credit2 also.

Thanks
--jyh


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