ublk: don't quiesce in ublk_ch_release
authorUday Shankar <ushankar@purestorage.com>
Fri, 8 Aug 2025 21:44:43 +0000 (15:44 -0600)
committerJens Axboe <axboe@kernel.dk>
Mon, 11 Aug 2025 13:57:37 +0000 (07:57 -0600)
commit212c928d01e9ea1d1c46a114650b551da8ca823e
tree255d3f6e8e5f5ae72ddfe13b359f052b3020cbc4
parentd5dd409812eca084e68208926bb629c8f708651f
ublk: don't quiesce in ublk_ch_release

ublk_ch_release currently quiesces the device's request_queue while
setting force_abort/fail_io.  This avoids data races by preventing
concurrent reads from the I/O path, but is not strictly needed - at this
point, canceling is already set and guaranteed to be observed by any
concurrently executing I/Os, so they will be handled properly even if
the changes to force_abort/fail_io propagate to the I/O path later.
Remove the quiesce/unquiesce calls from ublk_ch_release. This makes the
writes to force_abort/fail_io concurrent with the reads in the I/O path,
so make the accesses atomic.

Before this change, the call to blk_mq_quiesce_queue was responsible for
most (90%) of the runtime of ublk_ch_release. With that call eliminated,
ublk_ch_release runs much faster. Here is a comparison of the total time
spent in calls to ublk_ch_release when a server handling 128 devices
exits, before and after this change:

before: 1.11s
after: 0.09s

Signed-off-by: Uday Shankar <ushankar@purestorage.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20250808-ublk_quiesce2-v1-1-f87ade33fa3d@purestorage.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
drivers/block/ublk_drv.c