summaryrefslogtreecommitdiff
path: root/block/blk-softirq.c
diff options
context:
space:
mode:
authorTejun Heo <tj@kernel.org>2019-09-26 02:03:09 +0300
committerJens Axboe <axboe@kernel.dk>2019-09-26 10:12:00 +0300
commit7cd806a9a953f234b9865c30028f47fd738ce375 (patch)
treeb1679109d6942bcc7c1649ce407195653377a9c5 /block/blk-softirq.c
parent25d41e4aadb0788b4fae8a8fca90f437b9ebd727 (diff)
downloadlinux-7cd806a9a953f234b9865c30028f47fd738ce375.tar.xz
iocost: improve nr_lagging handling
Some IOs may span multiple periods. As latencies are collected on completion, the inbetween periods won't register them and may incorrectly decide to increase vrate. nr_lagging tracks these IOs to avoid those situations. Currently, whenever there are IOs which are spanning from the previous period, busy_level is reset to 0 if negative thus suppressing vrate increase. This has the following two problems. * When latency target percentiles aren't set, vrate adjustment should only be governed by queue depth depletion; however, the current code keeps nr_lagging active which pulls in latency results and can keep down vrate unexpectedly. * When lagging condition is detected, it resets the entire negative busy_level. This turned out to be way too aggressive on some devices which sometimes experience extended latencies on a small subset of commands. In addition, a lagging IO will be accounted as latency target miss on completion anyway and resetting busy_level amplifies its impact unnecessarily. This patch fixes the above two problems by disabling nr_lagging counting when latency target percentiles aren't set and blocking vrate increases when there are lagging IOs while leaving busy_level as-is. Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'block/blk-softirq.c')
0 files changed, 0 insertions, 0 deletions