Hello, On Wed, Mar 12, 2025 at 09:51:30AM +0800, Yu Kuai wrote: ... > In the case of dirty pages writeback, BIO is 4k, while RQ can be up to > hw_sectors_kb. Our user are limiting iops based on real disk capacity > and they found BIO merge will be broken. > > The idea way really is rq-qos based iops limit, which is after BIO merge > and BIO merge is ensured not borken. In this case, I have to suggest > them set a high iops limit or just remove the iops limit. I get that that particular situation may be worked around with what you're suggesting but you should be able to see that this would create the exact opposite problem for people who are limiting by the IOs they issue, which would be the majority of the existing users, so I don't think we can flip the meaning of the existing knobs. re. introducing new knobs or a switch, one thing to consider is that independent iops limits are not that useful to begin with. A device's iops capacity can vary drastically depending on e.g. IO sizes and there usually is no one good iops limit value that both doesn't get in the way and isolates the impact on other users, so it does feel like trying to polish something which is fundamentally flawed. Whether bio or rq based, can you actually achieve meaningful isolation with blk-throtl's iops/bw limits? If switching to rq based (or something approximating that) substantially improves the situation, adding new sets of knobs would make sense, but I'm skeptical this will be all that useful. If this is just going to be a coarse safety mechanism to guard against things going completely out of hands or throttle already known IO patterns, whether the limits are based on bio or rq doesn't make whole lot of difference. Thanks. -- tejun
