summaryrefslogtreecommitdiff
path: root/drivers/block/nbd.c
diff options
context:
space:
mode:
authorHou Tao <houtao1@huawei.com>2017-07-11 16:58:15 +0300
committerJens Axboe <axboe@kernel.dk>2017-07-12 17:32:04 +0300
commit3f7cb4f4130ca5693f0698211bf1e42945efbb8c (patch)
tree7aecf67d6851b4213a89bb1e632b42878ee3b2c8 /drivers/block/nbd.c
parent38c9140740eb0993924b676a111c164903163b1e (diff)
downloadlinux-3f7cb4f4130ca5693f0698211bf1e42945efbb8c.tar.xz
bfq: dispatch request to prevent queue stalling after the request completion
There are mq devices (eg., virtio-blk, nbd and loopback) which don't invoke blk_mq_run_hw_queues() after the completion of a request. If bfq is enabled on these devices and the slice_idle attribute or strict_guarantees attribute is set as zero, it is possible that after a request completion the remaining requests of busy bfq queue will stalled in the bfq schedule until a new request arrives. To fix the scheduler latency problem, we need to check whether or not all issued requests have completed and dispatch more requests to driver if there is no request in driver. The problem can be reproduced by running the following script on a virtio-blk device with nr_hw_queues as 1: #!/bin/sh dev=vdb # mount point for dev mp=/tmp/mnt cd $mp job=strict.job cat <<EOF > $job [global] direct=1 bs=4k size=256M rw=write ioengine=libaio iodepth=128 runtime=5 time_based [1] filename=1.data [2] new_group filename=2.data EOF echo bfq > /sys/block/$dev/queue/scheduler echo 1 > /sys/block/$dev/queue/iosched/strict_guarantees fio $job Signed-off-by: Hou Tao <houtao1@huawei.com> Reviewed-by: Paolo Valente <paolo.valente@linaro.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'drivers/block/nbd.c')
0 files changed, 0 insertions, 0 deletions