Re: [linux-next:master] [mm] 7b32f64bc5: pts.svt-av1.Preset13.Bosphorus4K.frames_per_second 45.8% regression

On Tue, Jul 28, 2026 at 11:33:22AM +0100, Pedro Falcato wrote:
> > With my conditional approach:
> >   At step 5, vmf->pgoff=896, vma_pages_left = 1024-896 = 128
> >   128 < 128 (the condition is false), so _max_index stays ULONG_MAX
>
> This is exactly what we're trying to solve.

> > The key point: when mprotect splits a large file mapping into adjacent
> > VMAs (common for ELF segments, or read-then-write patterns), there's no
> > benefit in preventing readahead from crossing the boundary, so the data is
> > still sequential in the file. The limit only helps when we're actually
> > near the end of useful data (within ra_pages of the VMA end).
>
> This is completely missing the point. This change tried to back off from
> reading _anything_ past the VMA _on purpose_, due to ELF file spillage.
> This patch reintroduces spillage in a very obfuscated way.

Hi Pedro,

I understand the ELF spillage concern. However, I think it is better to
distinguish two different scenarios:

1. ELF segment loading: .text is typically a few hundred KB to a few
   MB, access is random (e.g., instruction fetches jump around), and the
   data beyond the segment boundary (e.g., .rodata padding or another
   segment with different access patterns) is not useful to prefetch.

2. Sequential mmap of contiguous file data: SVT-AV1 maps frames
   sequentially from the same file, and the data beyond the current
   VMA boundary is the next thing to be accessed. Same applies to
   mprotect-split regions of a single large mapping.

In your earlier message on Jun 18 [1], you noted that SVT-AV1
"progressively mapping the file data for a given frame" and that the
old behavior of "page faults for a given frame starting readahead for
the next few frames" looks "reasonable". I totally agree, and my patch
tries to preserve exactly that behavior for the sequential case while
still limiting spillage for the ELF case.

Here's why the conditional check still handles ELF spillage:

For a typical ELF .text segment (512KB = 128 pages, ra_pages=128):
  - First fault: vma_pages_left = 128, 128 < 128 is false, no limit
    (but ra->size starts small, won't reach boundary yet)
  - When readahead ramps up and approaches the end:
    vma_pages_left < 128, _max_index is set, spillage is blocked.

For VM_EXEC VMAs, Frederick's patch already has a separate code path
that unconditionally limits readahead to VMA boundaries (the exec folio
order path). So ELF .text spillage is already handled regardless.

The regression comes from the non-VM_EXEC sequential path (mmap read
of data files), where blocking cross-VMA readahead has a real cost
with no benefit, the data is contiguous and will be needed.

The 45.8% fps regression and 870% major fault increase are not
acceptable tradeoffs for blocking readahead that would have been
useful. My patch preserves the anti-spillage behavior for the last
ra_pages of each VMA, while allowing the readahead machinery to work
as designed for the bulk of sequential access.

[1] https://lore.kernel.org/oe-lkp/ajQbXthzbr9xgUIM@pedro-suse/

Bo