All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuehai Xu <yuehaixu@gmail.com>
To: xen-devel@lists.xensource.com
Cc: George.Dunlap@eu.citrix.com,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	yhxu@wayne.edu, Keir.Fraser@eu.citrix.com
Subject: Question about the ability of credit scheduler to handle I/O and CPU intensive VMs
Date: Mon, 13 Sep 2010 17:37:18 -0400	[thread overview]
Message-ID: <AANLkTi=Ro24zg-yDPk1+=c0XsZSe2kNn8Gk07Bu4x0WN@mail.gmail.com> (raw)

Hi all,

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

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

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.

Any ideas?

Thanks,
Yuehai

             reply	other threads:[~2010-09-13 21:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-13 21:37 Yuehai Xu [this message]
2010-09-13 23:29 ` Question about the ability of credit scheduler to handle I/O and CPU intensive VMs Jeremy Fitzhardinge
2010-09-14  1:38   ` Yuehai Xu
     [not found] ` <AANLkTin9E1m_jFcj4Ak7nB9OxcQynrznpQ_nNPi_U7hN@mail.gmail.com>
2010-09-14 14:58   ` Yuehai Xu
2010-09-30 12:28   ` Yuehai Xu
2010-09-30 13:27     ` George Dunlap
2010-10-05  2:52       ` Yuehai Xu
2010-10-05 14:16         ` George Dunlap
2010-10-05 14:56           ` Yuehai Xu
2010-10-05 15:02             ` George Dunlap
2010-10-07 22:18               ` Yuehai Xu
2010-10-08  0:25                 ` Yuehai Xu
2010-10-08  9:57                   ` George Dunlap
2010-10-08 10:03                     ` George Dunlap
2010-10-08 10:11                       ` George Dunlap
2010-10-10  4:08                     ` Yuehai Xu
2010-10-10  8:30                       ` cendhu
2010-10-11 11:05                       ` George Dunlap
2010-10-12 12:42                         ` Yuehai Xu
2010-10-18 10:25                           ` George Dunlap
2010-10-05  4:30       ` question about lineat pagetable and mfn_x strongerwill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTi=Ro24zg-yDPk1+=c0XsZSe2kNn8Gk07Bu4x0WN@mail.gmail.com' \
    --to=yuehaixu@gmail.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Keir.Fraser@eu.citrix.com \
    --cc=jeremy@goop.org \
    --cc=xen-devel@lists.xensource.com \
    --cc=yhxu@wayne.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.