From: Nilay Shroff <nilay@linux.ibm.com>
To: linux-block@vger.kernel.org
Cc: axboe@kernel.dk, ming.lei@redhat.com, yukuai1@huaweicloud.com,
hch@lst.de, shinichiro.kawasaki@wdc.com, kch@nvidia.com,
gjoyce@ibm.com
Subject: [PATCHv3 0/3] block: blk-rq-qos: replace static key with atomic bitop
Date: Thu, 14 Aug 2025 13:54:56 +0530 [thread overview]
Message-ID: <20250814082612.500845-1-nilay@linux.ibm.com> (raw)
Hi,
This patchset replaces the use of a static key in the I/O path (rq_qos_
xxx()) with an atomic queue flag (QUEUE_FLAG_QOS_ENABLED). This change
is made to eliminate a potential deadlock introduced by the use of static
keys in the blk-rq-qos infrastructure, as reported by lockdep during
blktests block/005[1].
The original static key approach was introduced to avoid unnecessary
dereferencing of q->rq_qos when no blk-rq-qos module (e.g., blk-wbt or
blk-iolatency) is configured. While efficient, enabling a static key at
runtime requires taking cpu_hotplug_lock and jump_label_mutex, which
becomes problematic if the queue is already frozen — causing a reverse
dependency on ->freeze_lock. This results in a lockdep splat indicating
a potential deadlock.
To resolve this, we now gate q->rq_qos access with a q->queue_flags
bitop (QUEUE_FLAG_QOS_ENABLED), avoiding the static key and the associated
locking altogether.
I compared both static key and atomic bitop implementations using ftrace
function graph tracer over ~50 invocations of rq_qos_issue() while ensuring
blk-wbt/blk-iolatency were disabled (i.e., no QoS functionality). For
easy comparision, I made rq_qos_issue() noinline. The comparision was
made on PowerPC machine.
Static Key disabled (QoS is not configured):
5d0: 00 00 00 60 nop # patched in by static key framework
5d4: 20 00 80 4e blr # return (branch to link register)
Only a nop and blr (branch to link register) are executed — very lightweight.
atomic bitop (QoS is not configured):
5d0: 20 00 23 e9 ld r9,32(r3) # load q->queue_flags
5d4: 00 80 29 71 andi. r9,r9,32768 # check QUEUE_FLAG_QOS_ENABLED (bit 15)
5d8: 20 00 82 4d beqlr # return if bit not set
This performs an ld and andi. before returning. Slightly more work,
but q->queue_flags is typically hot in cache during I/O submission.
With Static Key (disabled):
Duration (us): min=0.668 max=0.816 avg≈0.750
With atomic bitop QUEUE_FLAG_QOS_ENABLED (bit not set):
Duration (us): min=0.684 max=0.834 avg≈0.759
As expected, both versions are almost similar in cost. The added latency
from an extra ld and andi. is in the range of ~9ns.
There're three patches in the series:
- First patch is a minor optimization which skips evaluating q->rq_qos
check in the re_qos_done_bio() as it's not needed.
- Second patch fixes a subtle issue in rq_qos_del() to ensure that
we decrement the block_rq_qos static key in rq_qos_del() when a
QoS policy is detached from the queue.
- Third patch replaces usage of block_rq_qos static key with atomic flag
QUEUE_FLAG_QOS_ENABLED and thus helps break cpu_hotplug_lock depedency
on freeze_lock and that eventually help to fix the lockdep splat.
As usual, feedback and review comments are welcome!
[1] https://lore.kernel.org/linux-block/4fdm37so3o4xricdgfosgmohn63aa7wj3ua4e5vpihoamwg3ui@fq42f5q5t5ic/
Changes from v2:
- Added a change to skip the q->rq_qos check in rq_qos_done_bio().
This is now part of the first patch in this series. (Yu Kuai)
- Added a separate patch to ensure block_rq_qos is decremented when
detaching a QoS policy in rq_qos_del(). This is now the second
patch in this series. (Yu Kuai)
- Folded the third patch from v2 into the new third patch, as patch
ordering changed (the second patch from v2 is now the third patch
in v3).
Link to v2: https://lore.kernel.org/all/20250805171749.3448694-1-nilay@linux.ibm.com/
Changes from v1:
- For debugging I made rq_qos_issue() noinline in my local workspace,
but then inadvertently it slipped through the patchset upstream. So
reverted it and made rq_qos_issue() inline again as earlier.
- Added Reported-by and Closes tags in the first patch, which I
obviously missed to add in the first version.
Link to v1: https://lore.kernel.org/all/20250804122125.3271397-1-nilay@linux.ibm.com/
Nilay Shroff (3):
block: skip q->rq_qos check in rq_qos_done_bio()
block: decrement block_rq_qos static key in rq_qos_del()
block: avoid cpu_hotplug_lock depedency on freeze_lock
block/blk-mq-debugfs.c | 1 +
block/blk-rq-qos.c | 8 +++----
block/blk-rq-qos.h | 48 +++++++++++++++++++++++++++---------------
include/linux/blkdev.h | 1 +
4 files changed, 37 insertions(+), 21 deletions(-)
--
2.50.1
next reply other threads:[~2025-08-14 8:26 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-14 8:24 Nilay Shroff [this message]
2025-08-14 8:24 ` [PATCHv3 1/3] block: skip q->rq_qos check in rq_qos_done_bio() Nilay Shroff
2025-08-14 8:59 ` Yu Kuai
2025-08-14 11:12 ` Ming Lei
2025-08-14 8:24 ` [PATCHv3 2/3] block: decrement block_rq_qos static key in rq_qos_del() Nilay Shroff
2025-08-14 9:14 ` Yu Kuai
2025-08-14 11:33 ` Ming Lei
2025-08-14 8:24 ` [PATCHv3 3/3] block: avoid cpu_hotplug_lock depedency on freeze_lock Nilay Shroff
2025-08-14 9:21 ` Yu Kuai
2025-08-14 12:44 ` Ming Lei
2025-08-14 12:57 ` Nilay Shroff
2025-08-14 13:38 ` Ming Lei
2025-08-14 14:31 ` Nilay Shroff
2025-08-15 0:13 ` Ming Lei
2025-08-15 1:04 ` Yu Kuai
2025-08-15 7:59 ` Ming Lei
2025-08-15 8:39 ` Yu Kuai
2025-08-15 9:43 ` Nilay Shroff
2025-08-15 13:24 ` Ming Lei
2025-08-15 18:33 ` Nilay Shroff
2025-08-16 1:01 ` Yu Kuai
2025-08-16 1:59 ` Ming Lei
2025-08-21 12:19 ` [PATCHv3 0/3] block: blk-rq-qos: replace static key with atomic bitop Nilay Shroff
2025-08-21 13:11 ` Jens Axboe
2025-08-21 13:11 ` 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=20250814082612.500845-1-nilay@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=axboe@kernel.dk \
--cc=gjoyce@ibm.com \
--cc=hch@lst.de \
--cc=kch@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=shinichiro.kawasaki@wdc.com \
--cc=yukuai1@huaweicloud.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.