All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Andrew Theurer <habanero@linux.vnet.ibm.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>, kvm-devel <kvm@vger.kernel.org>
Subject: Re: KVM performance vs. Xen
Date: Sun, 03 May 2009 19:20:41 +0300	[thread overview]
Message-ID: <49FDC459.3010800@redhat.com> (raw)
In-Reply-To: <49FA44F2.5050609@linux.vnet.ibm.com>

Andrew Theurer wrote:
>>
>> If the overhead is dominated by copying, then you won't see the 
>> difference.  Once the copying is eliminated, the comparison may yield 
>> different results.  We should certainly see a difference in context 
>> switches.
> I would like to test this the proper way.  What do I need to do to 
> ensure these copies are eliminated?  I am on a 2.6.27 kernel, am I 
> missing anything there?  Anthony, would you be willing to provide a 
> patch to support the changes in the block API?

You need a 2.6.30 host kernel plus a libc patch.  Or the linux-aio qemu 
patch.

>>
>> One cause of context switches won't be eliminated - the 
>> non-saturating workload causes us to switch to the idle thread, which 
>> incurs a heavyweight exit.  This doesn't matter since we're idle 
>> anyway, but when we switch back, we incur a heavyweight entry.
> I have not looked at the schedstat or ftrace yet, but will soon.  
> Maybe it will tell us a little more about the context switches.
>
> Here's a sample of the kvm_stat:

We have about 120K host_state_reloads/sec, 70K pio/sec, and 35K 
interrupts/sec.

That corresponds to 35K virtio notifications/sec (reasonable for 8 
cores), and 85K excess context switches/sec.  These can probably be 
eliminated by using linux-aio, except those due to idling.


-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2009-05-03 16:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-29 14:41 KVM performance vs. Xen Andrew Theurer
2009-04-29 15:20 ` Nakajima, Jun
2009-04-29 15:33   ` Andrew Theurer
2009-04-30  8:56 ` Avi Kivity
2009-04-30 12:49   ` Andrew Theurer
2009-04-30 13:02     ` Avi Kivity
2009-04-30 13:44       ` Andrew Theurer
2009-04-30 13:47         ` Anthony Liguori
2009-04-30 13:52         ` Avi Kivity
2009-04-30 13:45   ` Anthony Liguori
2009-04-30 13:53     ` Avi Kivity
2009-04-30 15:08       ` Anthony Liguori
2009-04-30 13:59     ` Avi Kivity
2009-04-30 14:04       ` Andrew Theurer
2009-04-30 15:11         ` Anthony Liguori
2009-04-30 15:19           ` Avi Kivity
2009-04-30 15:59             ` Anthony Liguori
2009-05-01  0:40             ` Andrew Theurer
2009-05-03 16:20               ` Avi Kivity [this message]
2009-04-30 15:09       ` Anthony Liguori
2009-04-30 16:41   ` Marcelo Tosatti

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=49FDC459.3010800@redhat.com \
    --to=avi@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=habanero@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    /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.