From: Stefan Hajnoczi <stefanha@gmail.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: qemu-devel@nongnu.org, Kevin Wolf <kwolf@redhat.com>,
Fam Zheng <famz@redhat.com>, Ming Lei <ming.lei@canonical.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Roman Pen <roman.penyaev@profitbricks.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 0/8] virtio-blk: multiqueue support
Date: Thu, 2 Jun 2016 17:19:41 -0700 [thread overview]
Message-ID: <20160603001941.GA12907@stefanha-x1.localdomain> (raw)
In-Reply-To: <1464657966-26186-1-git-send-email-stefanha@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2835 bytes --]
On Mon, May 30, 2016 at 06:25:58PM -0700, Stefan Hajnoczi wrote:
> v2:
> * Simplify s->rq live migration [Paolo]
> * Use more efficient bitmap ops for batch notification [Paolo]
> * Fix perf regression due to batch notify BH in wrong AioContext [Christian]
>
> The virtio_blk guest driver has supported multiple virtqueues since Linux 3.17.
> This patch series adds multiple virtqueues to QEMU's virtio-blk emulated
> device.
>
> Ming Lei sent patches previously but these were not merged. This series
> implements virtio-blk multiqueue for QEMU from scratch since the codebase has
> changed. Live migration support for s->rq was also missing from the previous
> series and has been added.
>
> It's important to note that QEMU's block layer does not support multiqueue yet.
> Therefore virtio-blk device processes all virtqueues in the same AioContext
> (IOThread). Further work is necessary to take advantage of multiqueue support
> in QEMU's block layer once it becomes available.
>
> I will post performance results once they are ready.
>
> Stefan Hajnoczi (8):
> virtio-blk: use batch notify in non-dataplane case
> virtio-blk: tell dataplane which vq to notify
> virtio-blk: associate request with a virtqueue
> virtio-blk: add VirtIOBlockConf->num_queues
> virtio-blk: multiqueue batch notify
> virtio-blk: live migrateion s->rq with multiqueue
> virtio-blk: dataplane multiqueue support
> virtio-blk: add num-queues device property
>
> hw/block/dataplane/virtio-blk.c | 68 +++++++++++----------
> hw/block/dataplane/virtio-blk.h | 2 +-
> hw/block/virtio-blk.c | 129 +++++++++++++++++++++++++++++++++++-----
> include/hw/virtio/virtio-blk.h | 8 ++-
> 4 files changed, 159 insertions(+), 48 deletions(-)
There is a significant performance regression due to batch notify:
$ ./analyze.py runs/
Name IOPS Error
unpatched-d6550e9ed2 19269820.2 ± 1.36%
unpatched-d6550e9ed2-2 19567358.4 ± 2.42%
v2-batch-only-f27ed9a4d9 16252227.2 ± 6.09%
v2-no-dataplane 14560225.4 ± 5.16%
v2-no-dataplane-2 14622535.6 ± 10.08%
v2-no-dataplane-3 13960670.8 ± 7.11%
unpatched-d6550e9ed2 is without this patch series.
v2-batch-only-f27ed9a4d9 is with Patch 1 only. v2-no-dataplane is with
the patch series (dataplane is not enabled in any of these tests).
Next I will compare unpatched dataplane against patched dataplane. I
want to make sure Patch 1 faithfully moved batch notify from dataplane
code to generic virtio-blk code without affecting performance.
If there is no difference then it means batch notify decreases
performance for some workloads (obviously not the same workload that
Ming Lei was running).
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-06-03 0:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-31 1:25 [Qemu-devel] [PATCH v2 0/8] virtio-blk: multiqueue support Stefan Hajnoczi
2016-05-31 1:25 ` [Qemu-devel] [PATCH v2 1/8] virtio-blk: use batch notify in non-dataplane case Stefan Hajnoczi
2016-05-31 1:26 ` [Qemu-devel] [PATCH v2 2/8] virtio-blk: tell dataplane which vq to notify Stefan Hajnoczi
2016-05-31 1:26 ` [Qemu-devel] [PATCH v2 3/8] virtio-blk: associate request with a virtqueue Stefan Hajnoczi
2016-05-31 1:26 ` [Qemu-devel] [PATCH v2 4/8] virtio-blk: add VirtIOBlockConf->num_queues Stefan Hajnoczi
2016-05-31 1:26 ` [Qemu-devel] [PATCH v2 5/8] virtio-blk: multiqueue batch notify Stefan Hajnoczi
2016-05-31 1:26 ` [Qemu-devel] [PATCH v2 6/8] virtio-blk: live migrateion s->rq with multiqueue Stefan Hajnoczi
2016-05-31 1:26 ` [Qemu-devel] [PATCH v2 7/8] virtio-blk: dataplane multiqueue support Stefan Hajnoczi
2016-05-31 1:26 ` [Qemu-devel] [PATCH v2 8/8] virtio-blk: add num-queues device property Stefan Hajnoczi
2016-06-03 0:19 ` Stefan Hajnoczi [this message]
2016-06-03 22:26 ` [Qemu-devel] [PATCH v2 0/8] virtio-blk: multiqueue support Stefan Hajnoczi
2016-06-04 15:49 ` Roman Penyaev
2016-06-06 15:16 ` Paolo Bonzini
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=20160603001941.GA12907@stefanha-x1.localdomain \
--to=stefanha@gmail.com \
--cc=borntraeger@de.ibm.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=ming.lei@canonical.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=roman.penyaev@profitbricks.com \
--cc=stefanha@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).