linux-kernel - Re: [PATCH] blk-throttle: support io merge over iops

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z9GrD-7tW6tKVimk@slm.duckdns.org>
Date: Wed, 12 Mar 2025 05:41:03 -1000
From: Tejun Heo <tj@...nel.org>
To: Yu Kuai <yukuai1@...weicloud.com>
Cc: Ming Lei <ming.lei@...hat.com>, axboe@...nel.dk, josef@...icpanda.com,
	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
	cgroups@...r.kernel.org, yi.zhang@...wei.com, yangerkun@...wei.com,
	"yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH] blk-throttle: support io merge over iops_limit

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