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
next prev parent 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: linkBe 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.