From: Gopal Malaviya <gopalmalaviya53@gmail.com>
To: akpm@linux-foundation.org, willy@infradead.org, jack@suse.cz
Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
fujunjie1@qq.com, vishal.moola@gmail.com,
roman.gushchin@linux.dev, Trace <tracekotae@gmail.com>,
stable@vger.kernel.org
Subject: [PATCH] mm/filemap: restart mmap readahead on sequential faults after many misses
Date: Mon, 9 Nov 2026 09:14:44 +0000 [thread overview]
Message-ID: <20261109091444.128521-1-gopalmalaviya53@gmail.com> (raw)
In-Reply-To: <20261105192517.228523-1-tracekotae@gmail.com>
Since commit 9b0fcac3cfe7 ("mm/filemap: do not count FAULT_FLAG_TRIED
retries as mmap hits"), about a hundred sparse mmap faults push
mmap_miss over MMAP_LOTSAMISS and turn off mmap read-around, as
intended. But mmap_miss only comes down on hits on pages that
read-around brought in, and with read-around off there are none. A file
that is then read sequentially gets a synchronous single-page read for
every page until it is opened again.
When a miss above the limit is on the page right after the previous
miss, start readahead the way a sequential read() miss does, with
page_cache_sync_ra(), and keep mmap_miss at its cap so that hits on
that small first window do not bring back full read-around for random
access.
Tested in a KVM guest (x86_64, 2 vCPUs, 3 GiB) with ext4 on virtio-blk.
"base" is mm-hotfixes-unstable. "95b8e" is commit 95b8e432265f ("mm: use
zone lock guard in __offline_isolated_pages()"), the last one before the
series of 9b0fcac3cfe7. Commit 0b9c0aeba938 ("mm/filemap: count only the
faulting address as a mmap hit"), the first of that series, gives the
same results as 95b8e for the reproducer.
Reproducer from the report, read_ahead_kb 128, major faults:
95b8e base patched
sequential only 1 1 1
sparse pass, then sequential 1 16384 2
sparse, MADV_SEQUENTIAL, sequential 512 512 512
sparse, close and reopen, sequential 1 1 1
Touching 1% of the pages of a cold 20 GiB file, larger than memory,
MiB read from disk:
read_ahead_kb 128 read_ahead_kb 8192
95b8e base patched 95b8e base patched
random 5656 215 215 344731 1032 1032
stride 2053 pages 6545 216 216 419003 992 992
random 2-page runs 2992 215 528 173093 1099 2248
random 4-page runs 1570 216 594 86797 1266 2301
After the sparse pass, reading 32 regions of 2 MiB in turn takes 512
major faults per region on base and 2 with this patch.
Not tested: NFS, the GPU workload from the report, and other
architectures and page sizes.
An AI assistant (Claude) helped with the analysis and the approach, and
wrote the test programs and drafts of the comment and this changelog.
I reviewed, implemented, built and tested the change.
Fixes: 9b0fcac3cfe7 ("mm/filemap: do not count FAULT_FLAG_TRIED retries as mmap hits")
Reported-by: Trace <tracekotae@gmail.com>
Closes: https://lore.kernel.org/all/20261105192517.228523-1-tracekotae@gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Gopal Malaviya <gopalmalaviya53@gmail.com>
---
Notes, not for the changelog:
- Keeping mmap_miss at its cap is the least obvious part. Without it,
hits on each small window keep mmap_miss near the limit: random 4-page
runs at read_ahead_kb 8192 read 25896 MiB instead of 2301. A cap of
MMAP_LOTSAMISS * 2 gave the same results as the full cap in all tests,
since each new run sets it again. The cost: a reader that jumps
between sequential runs stays at 2 faults per region, where without
the cap it is back to 1 after 16 regions.
- A full read-around on the adjacent miss instead of page_cache_sync_ra()
also fixes the report, but random 2-page runs on a 2600 MiB file at
read_ahead_kb 128 read 379 MiB instead of 76 (38 on base).
- At read_ahead_kb 8192, this guest's default, the reproducer shows 1
fault for "sparse pass, then sequential" even on base: the 8 MiB
windows reach the next sparse pages.
- Patched results matched within 1% over two runs (the 32-region test
ran once). checkpatch is clean; mm/filemap.o builds without warnings
with W=1 for x86_64 and i386.
- I can send the test programs if useful.
mm/filemap.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 371a4bbd06..1548021472 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -3398,9 +3398,27 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf)
/*
* Do we miss much more than hit in this file? If so,
* stop bothering with read-ahead. It will only hurt.
+ *
+ * But without read-around no hits are left to bring
+ * mmap_miss down again, so a file that turns sequential
+ * would stay without read-ahead. Remember where we missed,
+ * and treat a miss on the next page like a sequential
+ * read() miss: page_cache_sync_ra() starts with a small
+ * window and only grows it while access stays sequential.
+ * Keep mmap_miss at its limit, so that hits on that window
+ * do not bring back full read-around for random access.
*/
- if (mmap_miss > MMAP_LOTSAMISS)
+ if (mmap_miss > MMAP_LOTSAMISS) {
+ pgoff_t prev_index = (unsigned long long)ra->prev_pos >> PAGE_SHIFT;
+
+ ra->prev_pos = (loff_t)vmf->pgoff << PAGE_SHIFT;
+ if (vmf->pgoff - prev_index != 1)
+ return fpin;
+ WRITE_ONCE(ra->mmap_miss, MMAP_LOTSAMISS * 10);
+ fpin = maybe_unlock_mmap_for_io(vmf, fpin);
+ page_cache_sync_ra(&ractl, 1);
return fpin;
+ }
}
if (force_thp_readahead) {
base-commit: 09f140d2cb078edfcd08a40a23ead0bdceea30a4
--
2.43.0
prev parent reply other threads:[~2026-11-09 9:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 19:25 [REGRESSION] mm/filemap: mmap read-around stays off for an open file after sparse faults, since 7.2 Trace
2026-11-09 9:14 ` Gopal Malaviya [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261109091444.128521-1-gopalmalaviya53@gmail.com \
--to=gopalmalaviya53@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=fujunjie1@qq.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=regressions@lists.linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=stable@vger.kernel.org \
--cc=tracekotae@gmail.com \
--cc=vishal.moola@gmail.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®