From: Ming Lei <ming.lei@redhat.com>
To: Caleb Sander Mateos <csander@purestorage.com>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/17] ublk: avoid accessing ublk_queue to handle ublksrv_io_cmd
Date: Sat, 20 Sep 2025 17:32:27 +0800 [thread overview]
Message-ID: <aM50q-eujoY7uvwc@fedora> (raw)
In-Reply-To: <20250918014953.297897-1-csander@purestorage.com>
On Wed, Sep 17, 2025 at 07:49:36PM -0600, Caleb Sander Mateos wrote:
> For ublk servers with many ublk queues, accessing the ublk_queue in
> ublk_ch_uring_cmd_local() and the functions it calls is a frequent cache miss.
> The ublk_queue is only accessed for its q_depth and flags, which are also
> available on ublk_device. And ublk_device is already accessed for nr_hw_queues,
> so it will already be cached. Unfortunately, the UBLK_IO_NEED_GET_DATA path
> still needs to access the ublk_queue for io_cmd_buf, so it's not possible to
> avoid accessing the ublk_queue there. (Allocating a single io_cmd_buf for all of
> a ublk_device's I/Os could be done in the future.) At least we can optimize
> UBLK_IO_FETCH_REQ, UBLK_IO_COMMIT_AND_FETCH_REQ, UBLK_IO_REGISTER_IO_BUF, and
> UBLK_IO_UNREGISTER_IO_BUF.
> Using only the ublk_device and not the ublk_queue in ublk_dispatch_req() is also
> possible, but left for a future change.
The idea looks good: avoid to read ublk_queue since querying ublk_device is
inevitable & enough.
For the series,
Reviewed-by: Ming Lei <ming.lei@redhat.com>
BTW, 'const struct ublk_device *' can be passed for several helpers, and it
can be one follow-up.
Thanks,
Ming
next prev parent reply other threads:[~2025-09-20 9:32 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 1:49 [PATCH 00/17] ublk: avoid accessing ublk_queue to handle ublksrv_io_cmd Caleb Sander Mateos
2025-09-18 1:49 ` [PATCH 01/17] ublk: remove ubq check in ublk_check_and_get_req() Caleb Sander Mateos
2025-09-19 3:53 ` Ming Lei
2025-09-18 1:49 ` [PATCH 02/17] ublk: don't pass q_id to ublk_queue_cmd_buf_size() Caleb Sander Mateos
2025-09-19 4:04 ` Ming Lei
2025-09-18 1:49 ` [PATCH 03/17] ublk: don't pass ublk_queue to __ublk_fail_req() Caleb Sander Mateos
2025-09-20 8:52 ` Ming Lei
2025-09-18 1:49 ` [PATCH 04/17] ublk: add helpers to check ublk_device flags Caleb Sander Mateos
2025-09-20 8:54 ` Ming Lei
2025-09-18 1:49 ` [PATCH 05/17] ublk: don't dereference ublk_queue in ublk_ch_uring_cmd_local() Caleb Sander Mateos
2025-09-18 1:49 ` [PATCH 06/17] ublk: don't dereference ublk_queue in ublk_check_and_get_req() Caleb Sander Mateos
2025-09-18 1:49 ` [PATCH 07/17] ublk: pass ublk_device to ublk_register_io_buf() Caleb Sander Mateos
2025-09-18 1:49 ` [PATCH 08/17] ublk: don't access ublk_queue in ublk_register_io_buf() Caleb Sander Mateos
2025-09-18 1:49 ` [PATCH 09/17] ublk: don't access ublk_queue in ublk_daemon_register_io_buf() Caleb Sander Mateos
2025-09-18 1:49 ` [PATCH 10/17] ublk: pass q_id and tag to __ublk_check_and_get_req() Caleb Sander Mateos
2025-09-18 1:49 ` [PATCH 11/17] ublk: don't access ublk_queue in ublk_check_fetch_buf() Caleb Sander Mateos
2025-09-18 1:49 ` [PATCH 12/17] ublk: don't access ublk_queue in ublk_config_io_buf() Caleb Sander Mateos
2025-09-18 1:49 ` [PATCH 13/17] ublk: don't pass ublk_queue to ublk_fetch() Caleb Sander Mateos
2025-09-18 1:49 ` [PATCH 14/17] ublk: don't access ublk_queue in ublk_check_commit_and_fetch() Caleb Sander Mateos
2025-09-18 1:49 ` [PATCH 15/17] ublk: don't access ublk_queue in ublk_need_complete_req() Caleb Sander Mateos
2025-09-18 1:49 ` [PATCH 16/17] ublk: pass ublk_io to __ublk_complete_rq() Caleb Sander Mateos
2025-09-18 1:49 ` [PATCH 17/17] ublk: don't access ublk_queue in ublk_unmap_io() Caleb Sander Mateos
2025-09-20 9:32 ` Ming Lei [this message]
2025-09-20 12:39 ` [PATCH 00/17] ublk: avoid accessing ublk_queue to handle ublksrv_io_cmd Jens Axboe
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=aM50q-eujoY7uvwc@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).