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

[Suren Baghdasaryan]

On Fri, Jun 19, 2026 at 12:26 PM Pedro Falcato <pfalcato@xxxxxxx> wrote:
>
> On Fri, Jun 19, 2026 at 10:52:07AM -0700, Suren Baghdasaryan wrote:
> > On Fri, Jun 19, 2026 at 10:46 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
> > >
> > > On Fri, Jun 19, 2026 at 10:43:06AM -0700, Suren Baghdasaryan wrote:
> > > > > 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.
> > >
> > > If userspace is properly tuned, it doesn't need automatic readahead
> > > at all; it can disable it and issue manual readaheads.  The point of
> > > automatic readahead is to cope with userspace which is doing stupid
> > > things like calling read() for a single byte at a time.
> > >
> > > Could it have better defaults?  Maybe!  It's worth a try.  But those
> > > attempts need to have a very low bar for reversion when it turns out
> > > they affect other workloads.
> >
> > That what I meant in the last part of my reply :)
> >
> > But in general, I think that benchmark measuring "how many frames per
> > second a CPU can encode" should be revised so it doesn't depend on
> > file prefetching mechanisms. Otherwise it's measuring something else.
>
> To be clear, that's not (necessarily) a benchmark, the code we were
> looking at is their encoder app.

Ack.

>
> (it's also generally not possible to prefetch the whole thing into RAM
> because, well, raw video files are quite large)

For such streaminig workload I think read() would be more appropriate,
and the change limiting read-ahead by VMA size would not affect it.

>
> --
> Pedro