summaryrefslogtreecommitdiffstats
path: root/certs
diff options
context:
space:
mode:
authorOmar Sandoval <osandov@fb.com>2017-02-22 10:58:29 -0800
committerJens Axboe <axboe@fb.com>2017-02-23 11:55:46 -0700
commitda55f2cc78418dee88400aafbbaed19d7ac8188e (patch)
tree59e8fea4c15519bfd0cfed355f59bf30d5d8e03d /certs
parent2d19020b085eaf61d24377db27e8630cd9cff7ce (diff)
downloadop-kernel-dev-da55f2cc78418dee88400aafbbaed19d7ac8188e.zip
op-kernel-dev-da55f2cc78418dee88400aafbbaed19d7ac8188e.tar.gz
blk-mq: use sbq wait queues instead of restart for driver tags
Commit 50e1dab86aa2 ("blk-mq-sched: fix starvation for multiple hardware queues and shared tags") fixed one starvation issue for shared tags. However, we can still get into a situation where we fail to allocate a tag because all tags are allocated but we don't have any pending requests on any hardware queue. One solution for this would be to restart all queues that share a tag map, but that really sucks. Ideally, we could just block and wait for a tag, but that isn't always possible from blk_mq_dispatch_rq_list(). However, we can still use the struct sbitmap_queue wait queues with a custom callback instead of blocking. This has a few benefits: 1. It avoids iterating over all hardware queues when completing an I/O, which the current restart code has to do. 2. It benefits from the existing rolling wakeup code. 3. It avoids punting to another thread just to have it block. Signed-off-by: Omar Sandoval <osandov@fb.com> Signed-off-by: Jens Axboe <axboe@fb.com>
Diffstat (limited to 'certs')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud