All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Becker <ross.becker@gmail.com>
To: <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] virtio-blk performance regression and qemu-kvm
Date: Thu, 08 Mar 2012 15:56:03 -0800	[thread overview]
Message-ID: <CB7E8713.852BD%ross.becker@gmail.com> (raw)

I just joined in order to chime in here-

I'm seeing the exact same thing as Reeted;  I've got a machine with a
storage subsystem capable of 400k IOPs, and when I punch the storage up to
VMs, each VM seems to top out at around 15-20k IOPs.   I've managed to get
to 115k IOPs by creating 8 VMs, doing appropriate CPU pinning to spread
them amongst physical cores, and running IO in them simultaneously, but
I'm unable to get a single VM past 20k IOPs.

I'm using kvm-qemu 12.1.2, as distributed in RHEL 6.2.

The hardware is a Dell R910 chassis, with 4 intel E7 processors.  I am
poking LVM logical volume block devices directly up to VMs as disks,
format raw, virtio driver, write caching none, IO mode native.  Each VM
has 4 vCPUs.

I'm also using fio to do my testing.

The interesting thing is that throughput is actually pretty fantastic; I'm
able to push 6.3 GB/sec using 256k blocks, but the IOPs @ 4k block size
are poor.

I am happy to provide any config details, or try any tests suggested.


--Ross



             reply	other threads:[~2012-03-08 23:56 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-08 23:56 Ross Becker [this message]
2012-03-09 10:01 ` [Qemu-devel] virtio-blk performance regression and qemu-kvm Stefan Hajnoczi
  -- strict thread matches above, loose matches on Subject: below --
2012-02-10 14:36 Dongsu Park
2012-02-12 23:55 ` Rusty Russell
2012-02-21 16:45   ` Dongsu Park
2012-02-21 22:16     ` Rusty Russell
2012-02-13 11:57 ` Stefan Hajnoczi
2012-02-21 15:57   ` Dongsu Park
2012-02-21 17:27     ` Stefan Hajnoczi
2012-02-22 16:48       ` Dongsu Park
2012-02-22 19:53         ` Stefan Hajnoczi
2012-02-28 16:39           ` Martin Mailand
2012-02-28 17:05             ` Stefan Hajnoczi
2012-02-28 17:15               ` Martin Mailand
2012-02-29  8:38                 ` Stefan Hajnoczi
2012-02-29 13:12                   ` Martin Mailand
2012-02-29 13:44                     ` Stefan Hajnoczi
2012-02-29 13:52                       ` Stefan Hajnoczi
2012-03-05 16:13 ` Martin Mailand
2012-03-05 16:35   ` Stefan Hajnoczi
2012-03-05 16:44     ` Martin Mailand
2012-03-06 12:59       ` Stefan Hajnoczi
2012-03-06 22:07         ` Reeted
2012-03-06 22:07           ` Reeted
2012-03-07  8:04           ` Stefan Hajnoczi
2012-03-07 14:21             ` Reeted
2012-03-07 14:33               ` Stefan Hajnoczi
2012-03-07 14:33                 ` Stefan Hajnoczi
2012-03-07 10:39         ` Martin Mailand
2012-03-07 11:21           ` Paolo Bonzini
2012-03-06 14:32   ` Dongsu Park

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=CB7E8713.852BD%ross.becker@gmail.com \
    --to=ross.becker@gmail.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.