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

[Pedro Falcato <pfalcato@suse.de>]

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@infradead.org> 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.

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

-- 
Pedro