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: <9d87351a-8ea6-9ed9-7359-3963672cdc17@huaweicloud.com>
Date: Mon, 24 Mar 2025 10:06:29 +0800
From: Yu Kuai <yukuai1@...weicloud.com>
To: Tejun Heo <tj@...nel.org>, 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

Hi, Tejun!

在 2025/03/12 23:41, Tejun Heo 写道:
> 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.
> 

My apology for the late reply.

> 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.

Yes, I understand the current situation. I just feel blk-throttle have
no such capacity to limit IOs that are issuing from user. There could
also be filesystems, and data blocks can be fragmented.
> 
> 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.

It's not just fundamentally flawed, and the implementation is just too
one-sided. So what is the next step?

- remove iops limit since it's not that useful;
- swith iops limit to against disk;
- do nothing?
> 
> 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.

Most of our users will just set meaningful bps limit, however, since
iops limit is supported they will set it as well, without much knowledge
how it really works, causing some unexpected phenomenon. And for now,
we'll suggest not to set iops limit, no even a high limit.

Thanks,
Kuai

> 
> Thanks.
>