linux-kernel - Re: [LKP] Re: [mm/readahead] 793917d997: fio.read

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]

Date:   Thu, 16 Jun 2022 09:07:03 +0800
From:   Yin Fengwei <fengwei.yin@...el.com>
To:     Matthew Wilcox <willy@...radead.org>
CC:     LKML <linux-kernel@...r.kernel.org>, <lkp@...ts.01.org>,
        <lkp@...el.com>, <linux-mm@...ck.org>,
        <linux-fsdevel@...r.kernel.org>
Subject: Re: [LKP] Re: [mm/readahead] 793917d997: fio.read_iops -18.8%
 regression



On 6/15/2022 8:36 PM, Matthew Wilcox wrote:
> On Wed, Jun 15, 2022 at 02:38:24PM +0800, Yin Fengwei wrote:
>> On 4/19/2022 1:08 AM, Matthew Wilcox wrote:
>>>
>>> I'm on holiday today, but adding linux-fsdevel and linux-mm so relevant
>>> people know about this.
>>>
>>> Don't focus on the 18% regression, focus on the 240% improvement on the
>>> other benchmark ;-)
>>>
>>> Seriously, someone (probably me) needs to dig into what the benchmark
>>> is doing and understand whether there's a way to avoid (or decide this
>>> regression isn't relevant) while keeping the performance gains elsewhere.
>> With:
>> commit b9ff43dd27434dbd850b908e2e0e1f6e794efd9b
>> Author: Matthew Wilcox (Oracle) <willy@...radead.org>
>> Date:   Wed Apr 27 17:01:28 2022 -0400
>>
>>     mm/readahead: Fix readahead with large folios
>>
>> the regression is almost gone:
> 
> That makes sense.  I did think at the time that this was probably the
> cause of the problem.
> 
>> commit:
>>   18788cfa236967741b83db1035ab24539e2a21bb
>>   b9ff43dd27434dbd850b908e2e0e1f6e794efd9b
>>
>> 18788cfa23696774 b9ff43dd27434dbd850b908e2e0
>> ---------------- ---------------------------
>>        fail:runs  %reproduction    fail:runs
>>            |             |             |
>>        4698:9       -36360%        1426:3     dmesg.timestamp:last
>>        3027:9       -22105%        1037:3     kmsg.timestamp:last
>>          %stddev     %change         %stddev
>>              \          |                \
>>       0.39 ±253%      -0.3        0.09 ±104%  fio.latency_1000us%
>>       0.00 ±141%      +0.0        0.01        fio.latency_100ms%
>>      56.60 ±  5%     +10.3       66.92 ±  8%  fio.latency_10ms%
>>      15.65 ± 22%      -1.3       14.39 ± 17%  fio.latency_20ms%
>>       1.46 ±106%      -0.5        0.95 ± 72%  fio.latency_2ms%
>>      25.81 ± 25%      -9.2       16.59 ± 18%  fio.latency_4ms%
>>       0.09 ± 44%      +0.9        1.04 ± 22%  fio.latency_50ms%
>>       0.00 ±282%      +0.0        0.02 ±141%  fio.latency_750us%
>>      13422 ±  6%      -1.4%      13233        fio.read_bw_MBps   <-----
> 
> A stddev of 6% and a decline of 1.4%?  How many tests did you run
> to make sure that this is a real decline and not fluctuation of
> one-quarter-of-one-standard-devisation?
For this test case (fio-basic with the specific parameters), we ran it
9 times with commit 18788cfa236967741b83db1035ab24539e2a21bb and 3 times
with commit b9ff43dd27434dbd850b908e2e0e1f6e794efd9b.

The stddev for commit 18788cfa236967741b83db1035ab24539e2a21bb is 6%. The
test result for commit b9ff43dd27434dbd850b908e2e0e1f6e794efd9b is quite
stable. Its stddev is less than 1% so the value is not shown.

Specific for -1.4%, we don't think it's real regression. As you said, it's 
less than stddev and we don't know whether it's because of stddev or not.

The point here is the commit b9ff43dd27434dbd850b908e2e0e1f6e794efd9b could
fix this regression. Thanks.


Regards
Yin, Fengwei

> _______________________________________________
> LKP mailing list -- lkp@...ts.01.org
> To unsubscribe send an email to lkp-leave@...ts.01.org