aboutsummaryrefslogtreecommitdiff
path: root/drivers/block/drbd
diff options
context:
space:
mode:
authorGravatar Jens Axboe <axboe@kernel.dk> 2018-06-28 11:54:01 -0600
committerGravatar Jens Axboe <axboe@kernel.dk> 2018-06-29 07:52:31 -0600
commit1f57f8d442f8017587eeebd8617913bfc3661d3d (patch)
tree43058155d51cacd8a255d2ddc5b0f53d28d76004 /drivers/block/drbd
parentblock: Fix cloning of requests with a special payload (diff)
downloadlinux-1f57f8d442f8017587eeebd8617913bfc3661d3d.tar.gz
linux-1f57f8d442f8017587eeebd8617913bfc3661d3d.tar.bz2
linux-1f57f8d442f8017587eeebd8617913bfc3661d3d.zip
blk-mq: don't queue more if we get a busy return
Some devices have different queue limits depending on the type of IO. A classic case is SATA NCQ, where some commands can queue, but others cannot. If we have NCQ commands inflight and encounter a non-queueable command, the driver returns busy. Currently we attempt to dispatch more from the scheduler, if we were able to queue some commands. But for the case where we ended up stopping due to BUSY, we should not attempt to retrieve more from the scheduler. If we do, we can get into a situation where we attempt to queue a non-queueable command, get BUSY, then successfully retrieve more commands from that scheduler and queue those. This can repeat forever, starving the non-queuable command indefinitely. Fix this by NOT attempting to pull more commands from the scheduler, if we get a BUSY return. This should also be more optimal in terms of letting requests stay in the scheduler for as long as possible, if we get a BUSY due to the regular out-of-tags condition. Reviewed-by: Omar Sandoval <osandov@fb.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'drivers/block/drbd')
0 files changed, 0 insertions, 0 deletions