[PATCH v2] nvme: core: shorten duration of multipath namespace rescan

[Hannes Reinecke]

On 8/26/24 16:22, 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 at suse.com>
> ---
> v2: (all changes suggested by Sagi Grimberg)
>   - patch subject changed from "nvme: core: freeze multipath queue early in
>     nvme_update_ns_info()" to "nvme: core: shorten duration of multipath
>     namespace rescan"
>   - inserted comment explaining why blk_freeze_queue_start() is called early
>   - wait for queue to be frozen even if ret != 0
>   - make code structure more obvious vs. freeze_start / freeze_wait / unfreeze
> 
> Hannes and Daniel had already added Reviewed-by: tags to the v1 patch, but
> I didn't add them above, because the patch looks quite different now.
> 
> ---
>   drivers/nvme/host/core.c | 21 ++++++++++++++++-----
>   1 file changed, 16 insertions(+), 5 deletions(-)
> 
Reviewed-by: Hannes Reinecke <hare at suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare at suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich