From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: Chaitanya Kulkarni <chaitanyak@nvidia.com>,
Christoph Hellwig <hch@lst.de>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>, Keith Busch <kbusch@kernel.org>,
Sagi Grimberg <sagi@grimberg.me>,
Pavel Begunkov <asml.silence@gmail.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"virtualization@lists.linux.dev" <virtualization@lists.linux.dev>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"io-uring@vger.kernel.org" <io-uring@vger.kernel.org>
Subject: Re: don't reorder requests passed to ->queue_rqs
Date: Thu, 14 Nov 2024 05:16:03 +0100 [thread overview]
Message-ID: <20241114041603.GA8971@lst.de> (raw)
In-Reply-To: <2f7fa13a-71d9-4a8d-b8f4-5f657fdaab60@kernel.dk>
On Wed, Nov 13, 2024 at 01:51:48PM -0700, Jens Axboe wrote:
> Thanks for testing, but you can't verify any kind of perf change with
> that kind of setup. I'll be willing to bet that it'll be 1-2% drop at
> higher rates, which is substantial. But the reordering is a problem, not
> just for zoned devices, which is why I chose to merge this.
So I did not see any variation, but I also don't have access to a really
beefy setup right now. If there is a degradation it probably is that
touching rq_next for each request actually has an effect if the list is
big enough and they aren't cache hot any more. I can cook up a patch
that goes back to the scheme currently used upstream in nvme and virtio
that just cuts of the list at a hctx change instead of moving the
requests one by one now that the block layer doesn't mess up the order.
next prev parent reply other threads:[~2024-11-14 4:16 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-13 15:20 don't reorder requests passed to ->queue_rqs Christoph Hellwig
2024-11-13 15:20 ` [PATCH 1/6] nvme-pci: reverse request order in nvme_queue_rqs Christoph Hellwig
2024-11-13 19:10 ` Keith Busch
2024-11-13 15:20 ` [PATCH 2/6] virtio_blk: reverse request order in virtio_queue_rqs Christoph Hellwig
2024-11-13 19:03 ` Keith Busch
2024-11-13 19:05 ` Jens Axboe
2024-11-13 23:25 ` Michael S. Tsirkin
2024-11-13 15:20 ` [PATCH 3/6] block: remove rq_list_move Christoph Hellwig
2024-11-13 15:20 ` [PATCH 4/6] block: add a rq_list type Christoph Hellwig
2024-11-14 20:11 ` Nathan Chancellor
2024-11-15 9:10 ` Christoph Hellwig
2024-11-15 12:49 ` Jens Axboe
2024-11-15 19:38 ` Jens Axboe
2024-11-16 0:56 ` Nathan Chancellor
2024-11-13 15:20 ` [PATCH 5/6] block: don't reorder requests in blk_add_rq_to_plug Christoph Hellwig
2024-11-13 15:20 ` [PATCH 6/6] block: don't reorder requests in blk_mq_add_to_batch Christoph Hellwig
2024-11-13 18:33 ` don't reorder requests passed to ->queue_rqs Bart Van Assche
2024-11-13 18:39 ` Jens Axboe
2024-11-13 18:46 ` Jens Axboe
2024-11-13 20:36 ` Chaitanya Kulkarni
2024-11-13 20:51 ` Jens Axboe
2024-11-13 22:23 ` Chaitanya Kulkarni
2024-11-13 22:27 ` Jens Axboe
2024-11-14 4:16 ` Christoph Hellwig [this message]
2024-11-14 15:14 ` Jens Axboe
2024-11-18 15:23 ` Christoph Hellwig
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=20241114041603.GA8971@lst.de \
--to=hch@lst.de \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=chaitanyak@nvidia.com \
--cc=io-uring@vger.kernel.org \
--cc=jasowang@redhat.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mst@redhat.com \
--cc=sagi@grimberg.me \
--cc=virtualization@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.