-
Notifications
You must be signed in to change notification settings - Fork 0
block/blk-mq: fix RT kernel issues and interrupt context warnings #433
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: linus-master_base
Are you sure you want to change the base?
Conversation
|
Upstream branch: d26143b |
4a5ddea to
0ab4e8c
Compare
|
Upstream branch: aacb0a6 |
839fc61 to
46d87e9
Compare
0ab4e8c to
a2a6d78
Compare
|
Upstream branch: aacb0a6 |
46d87e9 to
0493523
Compare
a2a6d78 to
f962a4d
Compare
|
Upstream branch: 623fb99 |
Commit 679b1874eba7 ("block: fix ordering between checking
QUEUE_FLAG_QUIESCED request adding") introduced queue_lock acquisition
in blk_mq_run_hw_queue() to synchronize QUEUE_FLAG_QUIESCED checks.
On RT kernels (CONFIG_PREEMPT_RT), regular spinlocks are converted to
rt_mutex (sleeping locks). When multiple MSI-X IRQ threads process I/O
completions concurrently, they contend on queue_lock in the hot path,
causing all IRQ threads to enter D (uninterruptible sleep) state. This
serializes interrupt processing completely.
Test case (MegaRAID 12GSAS with 8 MSI-X vectors on RT kernel):
- Good (v6.6.52-rt): 640 MB/s sequential read
- Bad (v6.6.64-rt): 153 MB/s sequential read (-76% regression)
- 6-8 out of 8 MSI-X IRQ threads stuck in D-state waiting on queue_lock
The original commit message mentioned memory barriers as an alternative
approach. Use full memory barriers (smp_mb) instead of queue_lock to
provide the same ordering guarantees without sleeping in RT kernel.
Memory barriers ensure proper synchronization:
- CPU0 either sees QUEUE_FLAG_QUIESCED cleared, OR
- CPU1 sees dispatch list/sw queue bitmap updates
This maintains correctness while avoiding lock contention that causes
RT kernel IRQ threads to sleep in the I/O completion path.
Fixes: 679b1874eba7 ("block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding")
Cc: [email protected]
Signed-off-by: Ionut Nechita <[email protected]>
…context Fix warning "WARN_ON_ONCE(!async && in_interrupt())" that occurs during SCSI device scanning when blk_freeze_queue_start() calls blk_mq_run_hw_queues() synchronously from interrupt context. The issue happens during device removal/scanning when: 1. blk_mq_destroy_queue() -> blk_queue_start_drain() 2. blk_freeze_queue_start() calls blk_mq_run_hw_queues(q, false) 3. This triggers the warning in blk_mq_run_hw_queue() when in interrupt context Change the synchronous call to asynchronous to avoid running in interrupt context. Fixes: Warning in blk_mq_run_hw_queue+0x1fa/0x260 Signed-off-by: Ionut Nechita <[email protected]>
0493523 to
1402dc0
Compare
Pull request for series with
subject: block/blk-mq: fix RT kernel issues and interrupt context warnings
version: 2
url: https://patchwork.kernel.org/project/linux-block/list/?series=1035804