Commit 4e5dff41 authored by Jens Axboe's avatar Jens Axboe

blk-mq: improve heavily contended tag case

Even with a number of waitqueues, we can get into a situation where we
are heavily contended on the waitqueue lock. I got a report on spc1
where we're spending seconds doing this. Arguably the use case is nasty,
I reproduce it with one device and 1000 threads banging on the device.
But that doesn't mean we shouldn't be handling it better.

What ends up happening is that a thread will fail to get a tag, add
itself to the waitqueue, and subsequently get woken up when a tag is
freed - only to find itself going back to sleep on the waitqueue.

Instead of waking all threads, use an exclusive wait and wake up our
sbitmap batch count instead. This seems to work well for me (massive
improvement for this use case), and it survives basic testing. But I
haven't fully verified it yet.

An additional improvement is running the queue and checking for a new
tag BEFORE needing to add ourselves to the waitqueue.
Signed-off-by: default avatarJens Axboe <>
parent 1291a0d5
......@@ -134,12 +134,6 @@ unsigned int blk_mq_get_tag(struct blk_mq_alloc_data *data)
ws = bt_wait_ptr(bt, data->hctx);
drop_ctx = data->ctx == NULL;
do {
prepare_to_wait(&ws->wait, &wait, TASK_UNINTERRUPTIBLE);
tag = __blk_mq_get_tag(data, bt);
if (tag != -1)
* We're out of tags on this hardware queue, kick any
* pending IO submits before going to sleep waiting for
......@@ -155,6 +149,13 @@ unsigned int blk_mq_get_tag(struct blk_mq_alloc_data *data)
if (tag != -1)
prepare_to_wait_exclusive(&ws->wait, &wait,
tag = __blk_mq_get_tag(data, bt);
if (tag != -1)
if (data->ctx)
......@@ -462,7 +462,7 @@ static void sbq_wake_up(struct sbitmap_queue *sbq)
atomic_cmpxchg(&ws->wait_cnt, wait_cnt, wait_cnt + wake_batch);
wake_up_nr(&ws->wait, wake_batch);
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment