Re: [PATCH mm-hotfixses] Revert "mm: limit filemap_fault readahead to VMA boundaries"

[Lorenzo Stoakes]

+cc Suren, Pedro, David - I messed up the cc on this patch.

On Fri, Jun 19, 2026 at 05:52:38PM +0100, Matthew Wilcox wrote:
> On Fri, Jun 19, 2026 at 09:37:11AM -0700, Andrew Morton wrote:
> > On Fri, 19 Jun 2026 12:28:51 +0100 Lorenzo Stoakes <ljs@xxxxxxxxxx> wrote:
> >
> > > This reverts commit 7b32f64bc512b40b268776c5ac4d354b325b3197.
> > >
> > > This patch caused a significant performance regression, so revert it, and
> > > we can determine whether the approach is sensible or not moving forwards,
> > > and if so how to avoid this.
> > >
> > > There was a merge conflict with commit de97ae6222c1 ("mm/readahead: no
> > > PG_readahead on EOF"), care was taken to ensure that the revert retained the
> > > behaviour of this patch and cleanly reverts commit 7b32f64bc512 ("mm: limit
> > > filemap_fault readahead to VMA boundaries") only.
> >
> > I'm a little conflicted here.
> >
> > 7b32f64bc512 avoided readahead of "file pages outside the mapped
> > region", which is clearly desirable (arguably a bug fix?) and we care

I wouldn't say it's a bug fix? The kernel has always done this with no reported
bugs.

> > about performance of executable mappings.  Whereas it isn't clear that
> > we care about whatever the heck that test case was doing.
> >
> > IOW, the revert might make the kernel worse, overall.
> >
> > If someone plans to get down and analyse that test case then come up
> > with a new version of 7b32f64bc512 then OK.  Is there such a person?
> >
> > I'll park the revert in mm-unstable for now, but would prefer not to
> > rush it in until we better understand what's going on with that test
> > case and what can be done to address it.

As Willy points out [0], we've identified that it's a real usecase that we're
regressing.

There's likely others too in the real world.

This approach has also not been without debate in the past (see [1]), I think
this patch slipped under the radar on that front a bit.

So yeah, this does not to be reverted, and as a hotfix sooner rather than later.

>
> Suren did that work.
> https://lore.kernel.org/linux-mm/CAJuCfpH_Fp=J-m-kVZ3VVmqH0cAfNX6CQKWt3XmAJq1Rp9sFwQ@xxxxxxxxxxxxxx/

Thanks for highlighting that Willy (copied -> [0]).

Overall, if a patch causes a major regression in a core mm subsystem, people can
wait a cycle to re-evaluate.

Thanks, Lorenzo

[0]:https://lore.kernel.org/linux-mm/CAJuCfpH_Fp=J-m-kVZ3VVmqH0cAfNX6CQKWt3XmAJq1Rp9sFwQ@xxxxxxxxxxxxxx/
[1]:https://lore.kernel.org/linux-mm/CAC_TJvfG8GcwG_2w1o6GOTZS8tfEx2h9A91qsenYfYsX8Te=Bg@xxxxxxxxxxxxxx/