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?