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  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]
Date:   Fri, 27 Apr 2018 10:40:40 +0800
From:   Joseph Qi <>
To:     "" <>,
        Tejun Heo <>
Cc:     Paolo Valente <>,
        linux-block <>,
        Jens Axboe <>, Shaohua Li <>,
        Mark Brown <>,
        Linus Walleij <>,
        Ulf Hansson <>,
        LKML <>
Subject: Re: testing io.low limit for blk-throttle

Hi Jianchao,

On 18/4/27 10:09, wrote:
> Hi Tejun and Joseph
> On 04/27/2018 02:32 AM, Tejun Heo wrote:
>> Hello,
>> On Tue, Apr 24, 2018 at 02:12:51PM +0200, Paolo Valente wrote:
>>> +Tejun (I guess he might be interested in the results below)
>> Our experiments didn't work out too well either.  At this point, it
>> isn't clear whether io.low will ever leave experimental state.  We're
>> trying to find a working solution.
> Would you please take a look at the following two patches.
> In addition, when I tested blk-throtl io.low on NVMe card, I always got
> even if the iops has been lower than io.low limit for a while, but the
> due to group is not idle, the downgrade always fails.
>        tg->latency_target && tg->bio_cnt &&
> 		tg->bad_bio_cnt * 5 < tg->bio_cn

I'm afraid the latency check is a must for io.low. Because idle time
check can only apply to simple scenarios from my test.

Yes, in some cases last_low_overflow_time does have problems.
And for not downgrade properly, I've also posted two patches before,
waiting Shaohua's review. You can also have a try.


> the latency always looks well even the sum of two groups's iops has reached the top.
> so I disable this check on my test, plus the 2 patches above, the io.low
> could basically works.
> My NVMe card's max bps is ~600M, and max iops is ~160k.
> Here is my config
> io.low riops=50000 wiops=50000 rbps=209715200 wbps=209715200 idle=200 latency=10
> io.max riops=150000
> There are two cgroups in my test, both of them have same config.
> In addition, saying "basically work" is due to the iops of the two cgroup will jump up and down.
> such as, I launched one fio test per cgroup, the iops will wave as following:
> group0   30k  50k   70k   60k  40k
> group1   120k 100k  80k   90k  110k
> however, if I launched two fio tests only in one cgroup, the iops of two test could stay 
> about 70k~80k.
> Could help to explain this scenario ?
> Thanks in advance
> Jianchao

Powered by blists - more mailing lists