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

Message-ID: <YqnSWMQN58xBUEt/@casper.infradead.org>
Date:   Wed, 15 Jun 2022 13:36:40 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Yin Fengwei <fengwei.yin@...el.com>
Cc:     kernel test robot <oliver.sang@...el.com>,
        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 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?