public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Suwan Kim <suwan.kim027@gmail.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: mst@redhat.com, jasowang@redhat.com, pbonzini@redhat.com,
	virtualization@lists.linux-foundation.org,
	linux-block@vger.kernel.org, mgurtovoy@nvidia.com
Subject: Re: [PATCH] virtio-blk: support polling I/O
Date: Tue, 15 Mar 2022 22:55:04 +0900	[thread overview]
Message-ID: <YjCauO0lb2mzQENJ@localhost.localdomain> (raw)
In-Reply-To: <Yi9c5bhdDrQ1pLDY@stefanha-x1.localdomain>

On Mon, Mar 14, 2022 at 03:19:01PM +0000, Stefan Hajnoczi wrote:
> On Sat, Mar 12, 2022 at 12:28:32AM +0900, Suwan Kim wrote:
> > This patch supports polling I/O via virtio-blk driver. Polling
> > feature is enabled based on "VIRTIO_BLK_F_MQ" feature and the number
> > of polling queues can be set by QEMU virtio-blk-pci property
> > "num-poll-queues=N". This patch improves the polling I/O throughput
> > and latency.
> > 
> > The virtio-blk driver doesn't not have a poll function and a poll
> > queue and it has been operating in interrupt driven method even if
> > the polling function is called in the upper layer.
> > 
> > virtio-blk polling is implemented upon 'batched completion' of block
> > layer. virtblk_poll() queues completed request to io_comp_batch->req_list
> > and later, virtblk_complete_batch() calls unmap function and ends
> > the requests in batch.
> > 
> > virtio-blk reads the number of queues and poll queues from QEMU
> > virtio-blk-pci properties ("num-queues=N", "num-poll-queues=M").
> > It allocates N virtqueues to virtio_blk->vqs[N] and it uses [0..(N-M-1)]
> > as default queues and [(N-M)..(N-1)] as poll queues. Unlike the default
> > queues, the poll queues have no callback function.
> > 
> > Regarding HW-SW queue mapping, the default queue mapping uses the
> > existing method that condsiders MSI irq vector. But the poll queue
> > doesn't have an irq, so it uses the regular blk-mq cpu mapping.
> > 
> > To enable poll queues, "num-poll-queues=N" property of virtio-blk-pci
> > needs to be added to QEMU command line. For that, I temporarily
> > implemented the property on QEMU. Please refer to the git repository below.
> > 
> > 	git : https://github.com/asfaca/qemu.git #on master branch commit
> > 
> > For verifying the improvement, I did Fio polling I/O performance test
> > with io_uring engine with the options below.
> > (io_uring, hipri, randread, direct=1, bs=512, iodepth=64 numjobs=N)
> > I set 4 vcpu and 4 virtio-blk queues - 2 default queues and 2 poll
> > queues for VM.
> > (-device virtio-blk-pci,num-queues=4,num-poll-queues=2)
> > As a result, IOPS and average latency improved about 10%.
> > 
> > Test result:
> > 
> > - Fio io_uring poll without virtio-blk poll support
> > 	-- numjobs=1 : IOPS = 297K, avg latency = 214.59us
> > 	-- numjobs=2 : IOPS = 360K, avg latency = 363.88us
> > 	-- numjobs=4 : IOPS = 289K, avg latency = 885.42us
> > 
> > - Fio io_uring poll with virtio-blk poll support
> > 	-- numjobs=1 : IOPS = 332K, avg latency = 192.61us
> > 	-- numjobs=2 : IOPS = 371K, avg latency = 348.31us
> > 	-- numjobs=4 : IOPS = 321K, avg latency = 795.93us
> 
> Last year there was a patch series that switched regular queues into
> polling queues when HIPRI requests were in flight:
> https://lore.kernel.org/linux-block/20210520141305.355961-1-stefanha@redhat.com/T/
> 
> The advantage is that polling is possible without prior device
> configuration, making it easier for users.
> 
> However, the dynamic approach is a bit more complex and bugs can result
> in lost irqs (hung I/O). Christoph Hellwig asked for dedicated polling
> queues, which your patch series now delivers.
> 
> I think your patch series is worth merging once the comments others have
> already made have been addressed. I'll keep an eye out for the VIRTIO
> spec change to extend the virtio-blk configuration space, which needs to
> be accepted before the Linux can be merged.

Thanks for the feedback :)
There's a lot of history.. I will try to improve the patch.

It might take some time because it need more discussion about qemu
device property and I do this in my night time.

> > @@ -728,16 +749,82 @@ static const struct attribute_group *virtblk_attr_groups[] = {
> >  static int virtblk_map_queues(struct blk_mq_tag_set *set)
> >  {
> >  	struct virtio_blk *vblk = set->driver_data;
> > +	int i, qoff;
> > +
> > +	for (i = 0, qoff = 0; i < set->nr_maps; i++) {
> > +		struct blk_mq_queue_map *map = &set->map[i];
> > +
> > +		map->nr_queues = vblk->io_queues[i];
> > +		map->queue_offset = qoff;
> > +		qoff += map->nr_queues;
> > +
> > +		if (map->nr_queues == 0)
> > +			continue;
> > +
> > +		if (i == HCTX_TYPE_DEFAULT)
> > +			blk_mq_virtio_map_queues(&set->map[i], vblk->vdev, 0);
> > +		else
> > +			blk_mq_map_queues(&set->map[i]);
> 
> A comment would be nice here to explain that regular queues have
> interrupts and hence CPU affinity is defined by the core virtio code,
> but polling queues have no interrupts so we let the block layer assign
> CPU affinity.

Okay. I will add the comment in v2.

Regards,
Suwan Kim

  reply	other threads:[~2022-03-15 13:55 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-11 15:28 [PATCH] virtio-blk: support polling I/O Suwan Kim
2022-03-11 15:38 ` Michael S. Tsirkin
2022-03-11 16:07   ` Suwan Kim
2022-03-11 16:18     ` Michael S. Tsirkin
2022-03-11 16:38       ` Suwan Kim
2022-03-13 10:37     ` Max Gurtovoy
2022-03-14  9:43       ` Suwan Kim
2022-03-14 10:25         ` Max Gurtovoy
2022-03-14 11:15           ` Michael S. Tsirkin
2022-03-14 13:22             ` Suwan Kim
2022-03-14 15:12               ` Michael S. Tsirkin
2022-03-14 13:26             ` Max Gurtovoy
2022-03-14 15:15               ` Michael S. Tsirkin
2022-03-14 16:33                 ` Max Gurtovoy
2022-03-14 22:22                   ` Michael S. Tsirkin
2022-03-13 10:42 ` Max Gurtovoy
2022-03-14  9:55   ` Suwan Kim
2022-03-14 10:32     ` Max Gurtovoy
2022-03-14  6:14 ` Jason Wang
2022-03-14 12:33   ` Suwan Kim
2022-03-14 14:48     ` Stefan Hajnoczi
     [not found]     ` <CACGkMEujXYNE-88=m9ohjbeAj2F7CqEUes8gOUmasTNtwn2bUA@mail.gmail.com>
2022-03-15 14:43       ` Suwan Kim
2022-03-15 14:53         ` Michael S. Tsirkin
2022-03-16  2:02         ` Jason Wang
2022-03-16 11:25           ` Max Gurtovoy
2022-03-16 13:32           ` Suwan Kim
2022-03-16 15:32           ` Suwan Kim
2022-03-16 15:36             ` Max Gurtovoy
2022-03-16 16:00               ` Stefan Hajnoczi
2022-03-17  2:20             ` Jason Wang
2022-03-17 15:03               ` Suwan Kim
2022-03-14 15:19 ` Stefan Hajnoczi
2022-03-15 13:55   ` Suwan Kim [this message]
2022-03-16 12:20     ` Stefan Hajnoczi

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=YjCauO0lb2mzQENJ@localhost.localdomain \
    --to=suwan.kim027@gmail.com \
    --cc=jasowang@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=mgurtovoy@nvidia.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox