From: Stefan Hajnoczi <stefanha@redhat.com>
To: Li Feng <fengli@smartx.com>
Cc: Jens Axboe <axboe@kernel.dk>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
"open list:BLOCK LAYER" <linux-block@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
"open list:VIRTIO BLOCK AND SCSI DRIVERS"
<virtualization@lists.linux.dev>, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH] virtio_blk: set the default scheduler to none
Date: Thu, 7 Dec 2023 09:51:59 -0500 [thread overview]
Message-ID: <20231207145159.GB2147383@fedora> (raw)
In-Reply-To: <20231207043118.118158-1-fengli@smartx.com>
[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]
On Thu, Dec 07, 2023 at 12:31:05PM +0800, Li Feng wrote:
> virtio-blk is generally used in cloud computing scenarios, where the
> performance of virtual disks is very important. The mq-deadline scheduler
> has a big performance drop compared to none with single queue. In my tests,
> mq-deadline 4k readread iops were 270k compared to 450k for none. So here
> the default scheduler of virtio-blk is set to "none".
>
> Signed-off-by: Li Feng <fengli@smartx.com>
> ---
> drivers/block/virtio_blk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
This seems similar to commit f8b12e513b95 ("virtio_blk: revert
QUEUE_FLAG_VIRT addition") where changing the default sounded good in
theory but exposed existing users to performance regressions.
Christoph's suggestion back in 2009 was to introduce a flag in the
virtio-blk hardware interface so that the device can provide a hint from
the host side.
Do you have more performance data aside from 4k randread? My suggestion
would be for everyone with an interest to collect and share data so
there's more evidence that this new default works well for a range of
configurations.
I don't want to be overly conservative. The virtio_blk driver has
undergone changes in this regard from the legacy block layer to blk-mq
(without an I/O scheduler) to blk-mq (mq-deadline). Performance changed
at each step and that wasn't a showstopper, so I think we could default
to 'none' without a lot of damage. Let's just get more data.
Stefan
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index d53d6aa8ee69..5183ec8e00be 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -1367,7 +1367,7 @@ static int virtblk_probe(struct virtio_device *vdev)
> vblk->tag_set.ops = &virtio_mq_ops;
> vblk->tag_set.queue_depth = queue_depth;
> vblk->tag_set.numa_node = NUMA_NO_NODE;
> - vblk->tag_set.flags = BLK_MQ_F_SHOULD_MERGE;
> + vblk->tag_set.flags = BLK_MQ_F_SHOULD_MERGE | BLK_MQ_F_NO_SCHED_BY_DEFAULT;
> vblk->tag_set.cmd_size =
> sizeof(struct virtblk_req) +
> sizeof(struct scatterlist) * VIRTIO_BLK_INLINE_SG_CNT;
> --
> 2.42.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-12-07 14:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-07 4:31 [PATCH] virtio_blk: set the default scheduler to none Li Feng
2023-12-07 6:02 ` Jason Wang
2023-12-07 6:32 ` Li Feng
2023-12-07 6:38 ` Michael S. Tsirkin
2023-12-07 6:53 ` Chaitanya Kulkarni
2023-12-07 7:21 ` Li Feng
2023-12-07 9:48 ` Chaitanya Kulkarni
2023-12-07 14:51 ` Stefan Hajnoczi [this message]
2023-12-07 14:55 ` Paolo Bonzini
2023-12-07 15:19 ` Christoph Hellwig
2023-12-08 2:00 ` Ming Lei
2023-12-08 2:44 ` Keith Busch
2023-12-08 3:15 ` Jens Axboe
2023-12-08 3:54 ` Ming Lei
2023-12-08 5:55 ` Li Feng
2023-12-08 11:07 ` Paolo Bonzini
2023-12-25 14:20 ` Michael S. Tsirkin
2023-12-26 9:01 ` Li Feng
2023-12-26 9:05 ` Michael S. Tsirkin
2023-12-26 12:14 ` Li Feng
2023-12-26 15:38 ` Michael S. Tsirkin
2023-12-27 7:26 ` Li Feng
2023-12-27 10:06 ` Michael S. Tsirkin
2023-12-28 7:25 ` Li Feng
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=20231207145159.GB2147383@fedora \
--to=stefanha@redhat.com \
--cc=axboe@kernel.dk \
--cc=fengli@smartx.com \
--cc=hch@lst.de \
--cc=jasowang@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.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