public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 0/2] block: virtio-blk: support multi vq per virtio-blk
@ 2014-06-26  2:08 Ming Lei
  2014-06-26  2:08 ` [PATCH v2 1/2] include/uapi/linux/virtio_blk.h: introduce feature of VIRTIO_BLK_F_MQ Ming Lei
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Ming Lei @ 2014-06-26  2:08 UTC (permalink / raw)
  To: Jens Axboe, linux-kernel
  Cc: Rusty Russell, linux-api, virtualization, Michael S. Tsirkin,
	Stefan Hajnoczi, Paolo Bonzini

Hi,

These patches try to support multi virtual queues(multi-vq) in one
virtio-blk device, and maps each virtual queue(vq) to blk-mq's
hardware queue.

With this approach, both scalability and performance on virtio-blk
device can get improved.

For verifying the improvement, I implements virtio-blk multi-vq over
qemu's dataplane feature, and both handling host notification
from each vq and processing host I/O are still kept in the per-device
iothread context, the change is based on qemu v2.0.0 release, and
can be accessed from below tree:

	git://kernel.ubuntu.com/ming/qemu.git #v2.0.0-virtblk-mq.1

For enabling the multi-vq feature, 'num_queues=N' need to be added into
'-device virtio-blk-pci ...' of qemu command line, and suggest to pass
'vectors=N+1' to keep one MSI irq vector per each vq, and the feature
depends on x-data-plane.

Fio(libaio, randread, iodepth=64, bs=4K, jobs=N) is run inside VM to
verify the improvement.

I just create a small quadcore VM and run fio inside the VM, and
num_queues of the virtio-blk device is set as 2, but looks the
improvement is still obvious.

1), about scalability
- without mutli-vq feature
	-- jobs=2, thoughput: 145K iops
	-- jobs=4, thoughput: 100K iops
- with mutli-vq feature
	-- jobs=2, thoughput: 193K iops
	-- jobs=4, thoughput: 202K iops

2), about thoughput
- without mutli-vq feature
	-- thoughput: 145K iops
- with mutli-vq feature
	-- thoughput: 202K iops

So in my test, even for a quad-core VM, if the virtqueue number
is increased from 1 to 2, both scalability and performance can
get improved a lot.

TODO:
	- adjust vq's irq smp_affinity according to blk-mq hw queue's cpumask

V2: (suggestions from Michael and Dave Chinner)
	- allocate virtqueues' pointers dynamically
	- make sure the per-queue spinlock isn't kept in same cache line
	- make each queue's name different

V1:
	- remove RFC since no one objects
	- add '__u8 unused' for pending as suggested by Rusty
	- use virtio_cread_feature() directly, suggested by Rusty

Thanks,
--
Ming Lei



^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2014-07-09  1:13 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-26  2:08 [PATCH v2 0/2] block: virtio-blk: support multi vq per virtio-blk Ming Lei
2014-06-26  2:08 ` [PATCH v2 1/2] include/uapi/linux/virtio_blk.h: introduce feature of VIRTIO_BLK_F_MQ Ming Lei
2014-06-26  2:08 ` [PATCH v2 2/2] block: virtio-blk: support multi virt queues per virtio-blk device Ming Lei
2014-06-26  7:45   ` Michael S. Tsirkin
2014-06-26  8:23     ` Ming Lei
2014-06-26  5:05 ` [PATCH v2 0/2] block: virtio-blk: support multi vq per virtio-blk Jens Axboe
2014-06-26  5:28   ` Ming Lei
2014-06-26  7:46   ` Michael S. Tsirkin
2014-07-09  1:01   ` Rusty Russell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox