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

[Matthew Wilcox]

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
> 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.

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