Even though credit scheduler is the default VM scheduler in XEN, I
don't think it works well in the case of I/O plus CPU intensive cases.
The result below is from a simple test case. Suppose there are two
VMs, both of which has a single VCPU, these two VMs share a single
1. If I run a CPU intensive program in each VM, the percentage of PCPU
for each VCPU is 50% vs. 50%. This makes sense
2. However, If I run a CPU intensive program in a VM while another VM
runs an I/O intensive program, the percentage is : 83% vs. 17%.
Actually, the VM which only runs I/O intensive program needs little
CPU, but still, almost 17% of PCPU is occupied by this VM. The
throughput of I/O is 104MB/s, which is the peak throughput of my hard
3. Now, one VM runs a CPU intensive program while the other VM runs
CPU + I/O intensive program, the percentage of CPU is : 50% vs. 50%.
However, the I/O throughput is just 53MB/s, this doesn't make any
sense, only 50% of I/O bandwidth is used for VM.
4. Last case, both the two VMs only run a single I/O intensive
program, the throughput of I/O reaches to almost 100MB/s
The document http://www.xen.org/files/xensummit_intel09/George_Dunlap.pdf
has explained why credit scheduler doesn't work well for CPU+I/O
intensive workload, however, since nothing seems happened after this
short paper, at least the performance of I/O remains poor. Is it
because of some technical issues?
I know when a domU has some I/O events, it need to be waked up
first(put it into BOOST queue), however, as long as its VCPU is not
idle, it will be put back into UNDER queue, which prevents this domU
to be scheduled immediately. Is it possible that when a domU has an
I/O event, the scheduler gives it a very short period of time, say,
50us, to make sure that it can be scheduled at once? In that way, the
latency of I/O should be lowed down.
Xen-devel mailing list