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

[Suren Baghdasaryan]

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.