Re: [PATCH] blk-throtl: optimize IOPS throttle for large IO scenarios
From: brookxu <hidden>
Date: 2021-07-27 03:06:28
Also in:
linux-block, lkml
Tejun Heo wrote on 2021/7/27 5:46:
Hello, On Tue, Jul 20, 2021 at 12:35:54AM +0800, brookxu wrote:quoted
In order to avoid code duplication and IOPS stability problems caused by estimating the equivalent number of IOs, and to avoid potential deadlock problems caused by synchronization through queue_lock. I tried to count the number of splited IOs in the current window through two atomic counters. Add the value of the atomic variable when calculating io_disp[rw], which can also avoid the problem of inaccurate IOPS in large IO scenarios. How do you think of this approach? Thanks for your time.I guess it's okay but am still not a big fan of adding another hook. This is primarily because blk-throtl is sitting too early in the stack - e.g. rq_qos is doing the same thing but sits after the split path - and it's a bit nasty to add an additional hook for it. Do you think it can be an option to relocate the blk-throtl hooks to the same spots as rq-qos or, even better, make it use rq-qos?
Make blk-throttle use rq-qos may be more elegant. But I found that there may be at least one problem that is difficult to solve. blk-throttle supports separate throttle for read and write IOs, which means that we cannot suspend tasks during throttle, but rq-qos throttle IOs by suspending tasks. We may be able to relocate the blk-throttle hooks to the rq-qos hooks. Since we may not be able to replace the throttle hook, in this case, if we register a rq-qos to the system, part of the blk-throttle hooks is in rq-qos and part hooks not, which feels a bit confusing. In addition, we may need to implement more hooks, such as IO merge hook. Thanks for you time.
Thanks.