Re: squashfs performance regression and readahea

[Xiongwei Song <sxwjean@gmail.com>]

Hi Hsin-Yi,

On Mon, May 9, 2022 at 10:29 PM Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>
> On Mon, May 9, 2022 at 9:21 PM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Mon, May 09, 2022 at 08:43:45PM +0800, Xiongwei Song wrote:
> > > Hi Hsin-Yi and Matthew,
> > >
> > > With the patch from the attachment on linux 5.10, ran the command as I
> > > mentioned earlier,
> > > got the results below:
> > > 1:40.65 (1m + 40.65s)
> > > 1:10.12
> > > 1:11.10
> > > 1:11.47
> > > 1:11.59
> > > 1:11.94
> > > 1:11.86
> > > 1:12.04
> > > 1:12.21
> > > 1:12.06
> > >
> > > The performance has improved obviously, but compared to linux 4.18, the
> > > performance is not so good.
> > >
> I think you shouldn't compare the performance with 4.18 directly,
> since there might be other factors that impact the performance.

Make sense.

>I'd suggest comparing the same kernel version with:
> a) with this patch
> b) with c1f6925e1091 ("mm: put readahead pages in cache earlier") reverted.

With 9eec1d897139 ("squashfs: provide backing_dev_info in order to disable
read-ahead") reverted and applied 0001-WIP-squashfs-implement-readahead.patch,
test result on linux 5.18：
1:41.51 (1m + 41.51s)
1:08.11
1:10.37
1:11.17
1:11.32
1:11.59
1:12.23
1:12.08
1:12.76
1:12.51

performance worse 1 ~ 2s than linux 5.18 vanilla.

>
> According to https://lore.kernel.org/linux-mm/Ynfzh2ifG85MZEoN@casper.infradead.org/t/
> It seems to be a 3 sec difference?

5 ~ 6s difference.

Regards,
Xiongwei

>
> 1:37.16 (1m + 37.16s)
> 1:04.18
> 1:05.28
> 1:06.07
> 1:06.31
> 1:06.58
> 1:06.80
> 1:06.79
> 1:06.95
> 1:06.61
>
> > > Moreover, I wanted to test on linux 5.18. But I think I should revert
> > > 9eec1d897139 ("squashfs: provide backing_dev_info in order to disable
> > > read-ahead"),
> > > right?  Otherwise, the patch doesn't work?
> >
> > I've never seen patch 9eec1d897139 before.  If you're going to point
> > out bugs in my code, at least have the decency to cc me on it.  It
> > should never have gone in, and should be reverted so the problem can
> > be fixed properly.