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

[Andrew Morton]

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.