diff options
author | Kemeng Shi <shikemeng@huaweicloud.com> | 2023-01-16 17:51:46 +0800 |
---|---|---|
committer | Jens Axboe <axboe@kernel.dk> | 2023-01-29 20:03:49 -0700 |
commit | 0c3e09e8854bcd3f7c45de85007ed283342b3464 (patch) | |
tree | 7f1fe22e232ad6fec5adfa713a19fbc7a9203dd3 /block/partitions/sysv68.c | |
parent | b5fcf7871acb7f9a3a8ed341a68bd86aba3e254a (diff) |
block, bfq: correctly raise inject limit in bfq_choose_bfqq_for_injection
Function bfq_choose_bfqq_for_injection may temporarily raise inject limit
to one request if current inject_limit is 0 before search of the source
queue for injection. However the search below will reset inject limit to
bfqd->in_service_queue which is zero for raised inject limit. Then the
temporarily raised inject limit never works as expected.
Assigment limit to bfqd->in_service_queue in search is needed as limit
maybe overwriten to min_t(unsigned int, 1, limit) for condition that
a large in-flight request is on non-rotational devices in found queue.
So we need to reset limit to bfqd->in_service_queue for normal case.
Actually, we have already make sure bfqd->rq_in_driver is < limit before
search, then
-Limit is >= 1 as bfqd->rq_in_driver is >= 0. Then min_t(unsigned int,
1, limit) is always 1. So we can simply check bfqd->rq_in_driver with
1 instead of result of min_t(unsigned int, 1, limit) for larget request in
non-rotational device case to avoid overwritting limit and the bug is gone.
-For normal case, we have already check bfqd->rq_in_driver is < limit,
so we can return found bfqq unconditionally to remove unncessary check.
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20230116095153.3810101-2-shikemeng@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'block/partitions/sysv68.c')
0 files changed, 0 insertions, 0 deletions