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] [thread-next>] [day] [month] [year] [list]

Message-ID: <baba2f82-6c35-8c24-847c-32a002009b63@huaweicloud.com>
Date: Tue, 11 Mar 2025 11:08:00 +0800
From: Yu Kuai <yukuai1@...weicloud.com>
To: Tejun Heo <tj@...nel.org>, Ming Lei <ming.lei@...hat.com>
Cc: Yu Kuai <yukuai1@...weicloud.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,

在 2025/03/10 23:53, Tejun Heo 写道:
> Hello,
> 
> On Mon, Mar 10, 2025 at 10:16:46AM +0800, Ming Lei wrote:
> ...
>>> Yes, but it's a litter hard to explain to users the differece between IO
>>> split and IO merge, they just think IO split is the numer of IOs issued
>>> to disk, and IO merge is the number of IOs issued from user.
>>
>> Here it is really one trouble.
>>
>> a) Sometimes people think IOs wrt. IOPS means that the read/write IO
>> submitted from application, one typical example is `fio`.
>>
>> b) Sometimes people think it is the data observed from `iostat`.
>>
>> In a), io merge/split isn't taken into account, but b) does cover io
>> merge and split.
>>
>> So question is that what is the correct way for user to observe IOPS
>> wrt. iops throttle?
> 
> If we could go back in time, I think the right metric to use is
> hardware-seen IOPS as that's better correlated with the actual capacity
> available (the correlation is very flawed but still better) and the number
> of issued bio's can easily change depending on kernel implementation
> details.

Yes, I agree the right metric is to use b), which cover IO merge and
split(and also filesystem meta and log).

> 
> That said, I'm not sure about changing the behavior now. blk-throtl has
> mostly used the number of bios as long as it has existed and given that
> there can be a signficant difference between the two metrics, I'm not sure
> the change is justified at this point.

If we really concern about the behavior change, can we consider a new
flag that can switch to the old behavior? We'll see if any user will
complain.

Thanks,
Kuai

> 
> Thanks.
>