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

[Lorenzo Stoakes]

On Mon, Jun 22, 2026 at 11:26:18AM +0200, Jan Kara wrote:
> On Fri 19-06-26 12:33:43, Suren Baghdasaryan wrote:
> > 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.
>
> In fact if you look at that app, it has three different methods of reading
> the input frames (mmap, normal read, fully buffered file in memory) and one
> is chosen based on config option. So the benchmark apparently configures
> the mmap method of accessing the input file.
>
> Anyway I agree with you using mmap-frame-by-frame approach for this usecase
> is kind of odd but not completely insane and it does demostrate people do
> odd things like this. For others the usecase of Android doing tons of small
> sparse mmaps into executable might look odd as well :) So this seems to be
> one of the cases where it's difficult to please everybody with the same
> behavior and we usually stick to the legacy behavior in cases like that (as
> much as I personally find restricting mmap readahead to a VMA a sensible
> thing to do). We just need to figure out how to improve the Android
> usecase.

Reading the thread, I think we're all in agreement that this is a workload
that exists and we are regressing it here, thus the revert is the right
course of action.

Andrew - could we move this to the hotfixes branch please?

>
> 								Honza
> --
> Jan Kara <jack@xxxxxxxx>
> SUSE Labs, CR

Thanks, Lorenzo