Thread (14 messages) 14 messages, 5 authors, 2015-12-15

Re: [RFC PATCH 2/2] block: virtio-blk: support multi virt queues per virtio-blk device

From: Ming Lei <hidden>
Date: 2015-12-15 01:26:48
Also in: lkml

Hi Paolo,

On Mon, Dec 14, 2015 at 6:31 PM, Paolo Bonzini [off-list ref] wrote:

On 18/06/2014 06:04, Ming Lei wrote:
quoted
For virtio-blk, I don't think it is always better to take more queues, and
we need to leverage below things in host side:

- host storage top performance, generally it reaches that with more
than 1 jobs with libaio(suppose it is N, so basically we can use N
iothread per device in qemu to try to get top performance)

- iothreads' loading(if iothreads are at full loading, increasing
queues doesn't help at all)

In my test, I only use the current per-dev iothread(x-dataplane)
in qemu to handle 2 vqs' notification and precess all I/O from
the 2 vqs, and looks it can improve IOPS by ~30%.

For virtio-scsi, the current usage doesn't make full use of blk-mq's
advantage too because only one vq is active at the same time, so I
guess the multi vqs' benefit won't be very much and I'd like to post
patches to support that first, then provide test data with
more queues(8, 16).
Hi Ming Lei,

would you like to repost these patches now that MQ support is in the kernel?

Also, I changed my mind about moving linux-aio to AioContext.  I now
think it's a good idea, because it limits the number of io_getevents
syscalls. O:-)  So I would be happy to review your patches for that as well.
OK, I try to figure out a new version, and it might take a while since it is
close to festival season, :-)

Thanks,
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help