Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 15 Jun 2022 13:36:40 +0100
From:   Matthew Wilcox <willy@infradead.org>
To:     Yin Fengwei <fengwei.yin@intel.com>
Cc:     kernel test robot <oliver.sang@intel.com>,
        LKML <linux-kernel@vger.kernel.org>, lkp@lists.01.org,
        lkp@intel.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: [LKP] Re: [mm/readahead] 793917d997: fio.read_iops -18.8%
 regression
Message-ID: <YqnSWMQN58xBUEt/@casper.infradead.org>
References: <20220418144234.GD25584@xsang-OptiPlex-9020>
 <Yl2bKRcRqbcMmhji@casper.infradead.org>
 <1e8deaea-5a05-1846-d51c-b834beb9f23e@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1e8deaea-5a05-1846-d51c-b834beb9f23e@intel.com>
Precedence: bulk

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@infradead.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?