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

[Pedro Falcato]

On Fri, Jun 19, 2026 at 06:07:30PM +0100, Lorenzo Stoakes wrote:
> +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.

Yeah, the mmap usage on SVT-AV1 is a little suspicious, but I guess the
pattern may come up time and time again for people doing chunked mmap
reads. I think we need to take a closer look at this change.
> 
> 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.

Yeah, sadly it seems like the patch _may_ need a rather substantial rework :|
So I would err on the side of caution for now and revert it as well.

-- 
Pedro