[PATCH v8 0/1] block/blk-mq: use atomic_t for quiesce_depth to avoid lock contention on RT

"Ionut Nechita (Wind River)" <[email protected]> Thu, 9 Jul 2026 09:38:02 +0300
Newsgroups org.kernel.vger.linux-rt-users,dev.linux.lists.linux-rt-devel,org.kernel.vger.linux-block,org.kernel.vger.linux-kernel,org.kernel.vger.stable
Message-ID <[email protected]>
From: Ionut Nechita <[email protected]>

Hi Jens,

This is v8 of the fix for the PREEMPT_RT performance regression caused by
commit 6bda857bcbb86 ("block: fix ordering between checking
QUEUE_FLAG_QUIESCED request adding").

Changes since v7 (May 12):
- No code or commit-message-body changes; this is a tags-only respin.
  Rebased on linux-next (next-20260708); the patch applies cleanly with
  no context changes.
- Picked up Reviewed-by: Bart Van Assche <[email protected]> on 1/1.
- Added an "Assisted-by:" trailer per the new AI contribution guidance in
  Documentation/process/coding-assistants.rst, to record that Claude
  assisted with this patch and that checkpatch was the analysis tool run.
  As that document requires, the Signed-off-by / DCO certification is
  and remains mine as the human submitter; no Signed-off-by was added by
  the AI.

Changes since v6 (May 6):
- Reader-side barrier in blk_mq_run_hw_queue() changed from smp_rmb() to
  smp_mb().  The race closed by commit 6bda857bcbb86 is a store-buffer
  pattern: one CPU inserts a request and then reads the quiesce state,
  another CPU unquiesces and then reads "has pending work".  A full
  barrier is needed on *both* sides, not just a read barrier on the
  reader, so smp_mb() now pairs with the existing writer-side
  smp_mb__after_atomic().  Thanks to Bart Van Assche for pointing out
  that smp_rmb() was insufficient.
- Rewrote the in-code comments and the commit message to spell out which
  ordering the removed q->queue_lock acquisitions provided and how it is
  preserved.

The problem: on PREEMPT_RT, the spinlock_t q->queue_lock that commit
6bda857bcbb86 added to blk_mq_run_hw_queue() converts to a sleeping
rt_mutex.  blk_mq_run_hw_queue() runs from every MSI-X IRQ thread and
hits that lock on the common "nothing pending" path, so all IRQ threads
serialise and go to D-state.  On a Broadcom/LSI MegaRAID 12GSAS/PCIe
Secure SAS39xx (megaraid_sas, 128 MSI-X vectors, 120 hw queues),
throughput drops from 640 MB/s to 153 MB/s.

The fix takes the memory-barrier alternative and folds the quiesce
indicator into quiesce_depth itself: quiesce_depth becomes atomic_t,
QUEUE_FLAG_QUIESCED goes away, and no lock is left on the dispatch hot
path.

v7: https://lore.kernel.org/linux-block/[email protected]/

Ionut Nechita (1):
  block/blk-mq: use atomic_t for quiesce_depth to avoid lock contention
    on RT

 block/blk-core.c       |  1 +
 block/blk-mq-debugfs.c |  1 -
 block/blk-mq.c         | 69 ++++++++++++++++++++++++++----------------
 include/linux/blkdev.h |  9 ++++--
 4 files changed, 50 insertions(+), 30 deletions(-)


base-commit: b9810cd75b9fb56a3425d391cba3f608502bd474
--
2.54.0