diff options
author | Shaohua Li <shli@fb.com> | 2017-03-27 10:51:36 -0700 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2018-03-22 09:37:14 +0100 |
commit | 7cf6102fef4b4acfe5e8262926da99e4b8eabef8 (patch) | |
tree | 9b36c90cc57c36137d3e9d4a09f9de4fb531d419 /mm | |
parent | bbb325e7ebaf068d27b9a94c0aefcaf30926223b (diff) | |
download | linux-stable-7cf6102fef4b4acfe5e8262926da99e4b8eabef8.tar.gz linux-stable-7cf6102fef4b4acfe5e8262926da99e4b8eabef8.tar.bz2 linux-stable-7cf6102fef4b4acfe5e8262926da99e4b8eabef8.zip |
blk-throttle: make sure expire time isn't too big
[ Upstream commit 06cceedcca67a93ac7f7aa93bbd9980c7496d14e ]
cgroup could be throttled to a limit but when all cgroups cross high
limit, queue enters a higher state and so the group should be throttled
to a higher limit. It's possible the cgroup is sleeping because of
throttle and other cgroups don't dispatch IO any more. In this case,
nobody can trigger current downgrade/upgrade logic. To fix this issue,
we could either set up a timer to wakeup the cgroup if other cgroups are
idle or make sure this cgroup doesn't sleep too long. Setting up a timer
means we must change the timer very frequently. This patch chooses the
latter. Making cgroup sleep time not too big wouldn't change cgroup
bps/iops, but could make it wakeup more frequently, which isn't a big
issue because throtl_slice * 8 is already quite big.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions