Re: The caculation of the credit in credit_scheduler

[George Dunlap <George.Dunlap@eu.citrix.com>]

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 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