Re: [LKP] Re: [mm/readahead] 793917d997: fio.read_iops -18.8% regression

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxxxxxx>
>> 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@xxxxxxxxxxxx
> To unsubscribe send an email to lkp-leave@xxxxxxxxxxxx



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux