Hi,
在 2023/05/18 2:23, Bart Van Assche 写道:
On 5/17/23 00:49, Yu Kuai wrote:
在 2023/05/16 23:12, Bart Van Assche 写道:
I propose that we switch to one of these two approaches:
How about a smoothing method that the device with more io will share
more tag, and each device will get at least one tag?
Hi Yu,
hctx_may_queue() is called from the hot path (blk_mq_get_tag()). I'm
pretty sure that adding any nontrivial code in that path will cause a
performance (IOPS) regression. So I don't think that adding a smoothing
method in hctx_may_queue() is a realistic option.
Currently, fair share from hctx_may_queue() requires two
atomic_read(active_queues and active_requests), I think this smoothing
method can be placed into get_tag fail path, for example, the more times
a disk failed to get tag in a period of time, the more tag this disk can
get, and all the information can be updated here(perhaps directly
record how many tags a disk can get, then hctx_may_queue() still only
require 2 atomic_read()).
Thanks,
Bart
