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

[Suren Baghdasaryan]

On Fri, Jun 19, 2026 at 10:18 AM Pedro Falcato <pfalcato@xxxxxxx> wrote:
>
> 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.

Frame-by-frame mmapping for a streaming workoad is quite questionable
IMHO and I don't think we should be optimizing or encouraging such
usage, but I understand the reasoning for the revert.

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