Re: [PATCH] mm/filemap: let sequential faults restart mmap readahead

[Alireza Haddadi]

> On 11 Nov 2026, at 05:23, Gopal Malaviya <gopalmalaviya53@xxxxxxxxx> wrote:
>
Hi Gopal,

Thanks for testing this so thoroughly,
and for pointing me to Trace’s report.

> Hi Alireza,
>
> I had sent a different fix for the same regression [1], reported by
> Trace in [2]. Jan prefers yours, so I have dropped mine. I ran your
> patch, also with the v2 change you describe to Jan, through the tests
> I had: a KVM guest (x86_64, 2 vCPUs, 3 GiB), mm-hotfixes-unstable as
> of 2026-11-08, ext4 and XFS with 16 KiB blocks on virtio-blk,
> read_ahead_kb 128 unless noted.
>
> The reproducer from [2] (2000 single-page faults 1 MiB apart, then a
> 64 MiB sequential read), major faults in the sequential part:
>
>                       base   as posted   with v2 change
>  ext4                16384           2                2
>  XFS, 16 KiB blocks   4096        4096                2
>
That matches what I see here: on mm-new without the patch, XFS with
16k blocks take one fault per 16 KiB folio in the in-order read.
> Touching 1% of the pages of a cold 20 GiB file, larger than memory, in
> random runs of 1, 2 or 4 adjacent pages, MiB read from disk with the
> v2 change (first of two runs; the second was within 10%):
>
>                       read_ahead_kb 128     read_ahead_kb 8192
>                        base   with v2        base   with v2
>  random 4-page runs     240      1146        1200     57748
>

> The 4-page runs at read_ahead_kb 8192, which is what this guest's
> virtio-blk disk gets by default, read about 48 times more. As far as I
> can tell, each run now has two misses and up to two hits on the new
> window, so mmap_miss stays around MMAP_LOTSAMISS, and each time it is
> back at the limit the next random miss gets the full 8 MiB
> read-around. My patch ran into the same and kept mmap_miss at its cap
> on that path; something like that may help here, but you and Jan know
> this better.

This is a real problem, thanks for catching it. None of my tests had
short sequential runs at random places, so I missed it. I’ll reproduce
it here and rework the patch before sending v2. I want to compare
keeping mmap_miss high on that path, as you did, with only restarting
readahead once the fault continues a longer run of cached pages.

Jan thanks for being OK with the min-order change. Given this, v2
will change more than, so I won’t carry your Reviewed-by over.
I’d be glad if you could take another look at v2.
>
> On the Fixes tag: with the commits of the series built one by one,
> commit 0b9c0aeba938 ("mm/filemap: count only the faulting address as
> a mmap hit") alone does not show the problem (1 major fault with the
> reproducer), and commit 9b0fcac3cfe7 ("mm/filemap: do not count
> FAULT_FLAG_TRIED retries as mmap hits") does (16384). [2] is the same
> regression, in case you want to add Reported-by and Closes tags for
> regzbot.
>
I only tested reverting both commits together, so I’ll check this and fix the
tag in v2, and add Reported-by and Closes for Trace’s report.

> I am happy to run these again on your v2. The tests were set up with
> the help of an AI assistant.

That would be great, thank you. Could you share the short-run test,
So I can run the same here while working on it?

Best Regards,
Alireza









När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy