[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/9] virtio-blk: multiqueue support

From: Christian Borntraeger
Subject: Re: [Qemu-devel] [PATCH 0/9] virtio-blk: multiqueue support
Date: Tue, 24 May 2016 14:51:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0

On 05/21/2016 01:40 AM, Stefan Hajnoczi wrote:
> 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 (9):
>   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
>   vmstate: add VMSTATE_VARRAY_UINT32_ALLOC
>   virtio-blk: live migrate 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           | 200 
> ++++++++++++++++++++++++++++++++++++----
>  include/hw/virtio/virtio-blk.h  |  13 ++-
>  include/migration/vmstate.h     |  10 ++
>  5 files changed, 241 insertions(+), 52 deletions(-)

With 2.6 I see 2 host threads consuming a CPU when running fio in a single CPU
guest with a null-blk device and iothread for that disk. (the vcpu thread and
the iothread). With this patchset the main thread also consumes almost 80% of a
CPU doing polling in main_loop_wait. I have not even changes the num-queues 

So in essence 3 vs 2 host cpus.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]