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

[Jan Kara]

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.

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