All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yin Fengwei <fengwei.yin@intel.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: 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
Date: Thu, 16 Jun 2022 09:07:03 +0800	[thread overview]
Message-ID: <304d2dff-ef46-180e-0840-8c6480de1f06@intel.com> (raw)
In-Reply-To: <YqnSWMQN58xBUEt/@casper.infradead.org>



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@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?
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@lists.01.org
> To unsubscribe send an email to lkp-leave@lists.01.org

WARNING: multiple messages have this Message-ID (diff)
From: Yin Fengwei <fengwei.yin@intel.com>
To: lkp@lists.01.org
Subject: Re: [mm/readahead] 793917d997: fio.read_iops -18.8% regression
Date: Thu, 16 Jun 2022 09:07:03 +0800	[thread overview]
Message-ID: <304d2dff-ef46-180e-0840-8c6480de1f06@intel.com> (raw)
In-Reply-To: <YqnSWMQN58xBUEt/@casper.infradead.org>

[-- Attachment #1: Type: text/plain, Size: 3198 bytes --]



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@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?
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(a)lists.01.org
> To unsubscribe send an email to lkp-leave(a)lists.01.org

  reply	other threads:[~2022-06-16  1:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-18 14:42 [mm/readahead] 793917d997: fio.read_iops -18.8% regression kernel test robot
2022-04-18 14:42 ` kernel test robot
2022-04-18 17:08 ` Matthew Wilcox
2022-04-18 17:08   ` Matthew Wilcox
2022-06-15  6:38   ` [LKP] " Yin Fengwei
2022-06-15  6:38     ` Yin Fengwei
2022-06-15 12:36     ` [LKP] " Matthew Wilcox
2022-06-15 12:36       ` Matthew Wilcox
2022-06-16  1:07       ` Yin Fengwei [this message]
2022-06-16  1:07         ` Yin Fengwei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=304d2dff-ef46-180e-0840-8c6480de1f06@intel.com \
    --to=fengwei.yin@intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=lkp@lists.01.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.