Re: squashfs performance regression and readahea

[Hsin-Yi Wang <hsinyi@chromium.org>]

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

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

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.