Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
blk-mq: make restart mechanism more reliable
BLK_STS_RESOURCE can be returned from driver when any resource is running out of. And the resource may not be related with tags, such as kmalloc(GFP_ATOMIC), when queue is idle under this kind of BLK_STS_RESOURCE, restart can't work any more, then IO hang may be caused. This patch deals with this situation by running the queue after 10ms, and serves as the last straw to avoid IO hang. The introduced cost is small and can be ignored because: - the combined condition of 'need_restart and BLK_STS_RESOURCE' can seldom be triggered - for TAG_SHARED, hctx->nr_active is used to check if queue is busy - for non-TAG_SHARED, sbitmap_any_bit_set() is used to check if queue is busy. When BLK_STS_RESOURCE is returned and SCHED_RESTART is set, most of times it means there are too many inflight requests, and sbitmap_any_bit_set() can return very quickly. Test has been run on dm-mpath over scsi-debug, which is setup as: - modprobe scsi_debug virtual_gb=128 submit_queues=1 max_luns=2 ndelay=1000 max_queue=4 - fio on dm-mpath, randread, bs:4k, libaio, dio, 32jobs, 64 iodepth - run/restart observed from debugfs(thanks Mike for enabling blk-mq debugfs on dm-rq) root@ming:/sys/kernel/debug/block/dm-4/hctx0# cat run 19235342 root@ming:/sys/kernel/debug/block/dm-4/hctx0# cat restart 45 So from the above debugfs info, this patch's effect on perfomance can be ignored, because this condition is too difficult to trigger(0.0002339%) Signed-off-by: Ming Lei <ming.lei@redhat.com>
- Loading branch information