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

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

>-----Original Message-----
>From: George Dunlap [mailto:George.Dunlap@xxxxxxxxxxxxx]
>Sent: Tuesday, November 09, 2010 10:27 PM
>To: Jiang, Yunhong
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Dong, Eddie; Zhang, Xiantao
>Subject: Re: The caculation of the credit in credit_scheduler
>
>On 05/11/10 07:06, Jiang, Yunhong wrote:
>> 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 suspect that the real reason you're having trouble is that pinning and
>the credit mechanism don't work very well together.  Instead of pinning,
>have you tried using the cpupools interface to make a 2-cpu pool to put
>the VMs into?  That should allow the credit to be divided appropriately.

I have a quick look in the code, and seems the cpu pool should not help on such 
situation. The CPU poll only cares about the CPUs a domain can be scheduled, 
but not about the credit caculation.

Will do the experiment later.

Thanks
--jyh

>
>> I didn't try credit2, so no idea if this will happen to credit2 also.
>
>Credit2 may do better at dividing.  However, it doesn't implement
>pinning (just ignores it).  So you couldn't do your test unless you used
>cpupools, or limited cpus=2 to Xen's commandline.
>
>Also, credit2 isn't yet designed to handle 64 cpus yet, so it may not
>work very well on a system with 64 cores.
>
>  -George

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