From: Niklas Cassel <cassel@kernel.org>
To: Martin Wilck <martin.wilck@suse.com>
Cc: Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
Hannes Reinecke <hare@suse.de>, Daniel Wagner <dwagner@suse.de>,
Stuart Hayes <stuart.w.hayes@gmail.com>,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH] nvme: core: freeze multipath queue early in nvme_update_ns_info()
Date: Fri, 23 Aug 2024 15:38:43 +0200 [thread overview]
Message-ID: <ZsiQ4yCji0PexMQ-@ryzen.lan> (raw)
In-Reply-To: <20240822201413.112268-1-mwilck@suse.com>
On Thu, Aug 22, 2024 at 10:14:13PM +0200, Martin Wilck wrote:
> For multipath devices, nvme_update_ns_info() needs to freeze both
> the queue of the path and the queue of the multipath device. For
> both operations, it waits for one RCU grace period to pass, ~25ms
> on my test system. By calling blk_freeze_queue_start() for the
> multipath queue early, we avoid waiting twice; tests using ftrace
> have shown that the second blk_mq_freeze_queue_wait() call finishes
> in just a few microseconds. The path queue is unfrozen before
> calling blk_mq_freeze_queue_wait() on the multipath queue, so that
> possibly outstanding IO in the multipath queue can be flushed.
>
> I tested this using the "controller rescan under I/O load" test
> I submitted recently [1].
>
> [1] https://lore.kernel.org/linux-nvme/20240822193814.106111-3-mwilck@suse.com/T/#u
>
> Signed-off-by: Martin Wilck <mwilck@suse.com>
> ---
> drivers/nvme/host/core.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 33fa01c599ad..e2454398c660 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -2217,6 +2217,9 @@ static int nvme_update_ns_info(struct nvme_ns *ns, struct nvme_ns_info *info)
> bool unsupported = false;
> int ret;
>
> + if (nvme_ns_head_multipath(ns->head))
> + blk_freeze_queue_start(ns->head->disk->queue);
> +
From someone reading this code, it looks quite similar to
nvme_mpath_start_freeze().
Perhaps create a new helper, with proper kdoc, and possibly also add kdoc to
nvme_mpath_start_freeze(), so that a user can easily tell (from the kdoc)
when to use which function.
Kind regards,
Niklas
next prev parent reply other threads:[~2024-08-23 13:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-22 20:14 [PATCH] nvme: core: freeze multipath queue early in nvme_update_ns_info() Martin Wilck
2024-08-23 6:45 ` Hannes Reinecke
2024-08-23 7:00 ` Daniel Wagner
2024-08-23 13:38 ` Niklas Cassel [this message]
2024-08-23 15:26 ` Martin Wilck
2024-08-23 15:51 ` Niklas Cassel
2024-08-25 8:28 ` Sagi Grimberg
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=ZsiQ4yCji0PexMQ-@ryzen.lan \
--to=cassel@kernel.org \
--cc=axboe@kernel.dk \
--cc=dwagner@suse.de \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=martin.wilck@suse.com \
--cc=sagi@grimberg.me \
--cc=stuart.w.hayes@gmail.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 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.