[REGRESSION] mm/filemap: mmap read-around stays off for an open file after sparse faults, since 7.2

[REGRESSION] mm/filemap: mmap read-around stays off for an open file after sparse faults, since 7.2

[Trace]

Hello,

since 7.2, once an open file has taken more than MMAP_LOTSAMISS mmap
misses, it gets no more mmap read-around, even if the access then turns
sequential. For a reader that does not run into pages an earlier
read-around brought in, it stays that way until the file is opened
again. Each later page is a synchronous 4 KiB read, which on NFS is a
round trip.

I think it comes from this series:

  0b9c0aeba938 ("mm/filemap: count only the faulting address as a mmap hit")
  9b0fcac3cfe7 ("mm/filemap: do not count FAULT_FLAG_TRIED retries as mmap hits")

I have not bisected or built a revert. By reading mm/filemap.c, v7.1
and the current 6.18.y have the old accounting and v7.2 onwards the new.
I measured 7.3.1 and 6.18.60, and the program below also gives 16384
on 7.2.14 (with the zen patches) on a SATA SSD. do_sync_mmap_readahead()
and do_async_mmap_readahead() are unchanged from v7.3 in next-20261103
and in mm-unstable, mm-hotfixes-unstable and mm-new of 2026-11-03.

As I read it: above MMAP_LOTSAMISS, do_sync_mmap_readahead() returns
without reading, and mmap_miss only goes down on a hit. With no
read-around the next page is not in the cache, so the next fault is
another miss, and nothing lowers the counter again. Before the series,
the retry after each read-around counted the pages it had just brought
in, so a sparse reader did not reach the limit. The series' tests run
random, stride and sequential access each on its own, not one after
another on the same open file.

The program below writes a 2600 MiB file, drops it with
POSIX_FADV_DONTNEED, touches 2000 pages 1 MiB apart through a private
mapping, then reads 64 MiB sequentially and counts major faults. x86_64,
4 KiB pages, read_ahead_kb 128, ext4, plenty of free memory (7.3.1 on
NVMe, 6.18.60 on a SATA SSD):

                                          7.3.1   6.18.60
  sequential only                             1         1
  sparse pass, then sequential            16384         1
  sparse, MADV_SEQUENTIAL, sequential       512       512
  sparse, close and reopen, sequential        1         1

The same pattern in a Python version, on 7.3.1, on NFS v4.2 over 1 GbE
through WireGuard: 80-90 MiB/s with no sparse pass, 5.7 MiB/s after it.

How I met it: PyTorch loading a model from safetensors on NFS, on a
Radeon AI PRO R9700 with ROCm, where the driver faults in the mapping:

  folio_wait_bit_common
  nfs_do_read_folio
  nfs_read_folio
  filemap_read_folio
  filemap_fault
  __do_fault
  do_fault
  __handle_mm_fault
  handle_mm_fault
  hmm_range_fault_locked
  amdgpu_hmm_range_get_pages
  svm_range_validate_and_map
  svm_range_set_attr
  kfd_ioctl

safetensors maps the whole file (torch.UntypedStorage.from_file,
MAP_PRIVATE) and builds one tensor view per entry, which takes one
read fault per tensor, mostly on its last page. A model file holds
hundreds of tensors spread over the file, so mmap_miss passes
MMAP_LOTSAMISS within a few seconds of the mmap, before any weight is
read (bpftrace on filemap_fault, reading file->f_ra.mmap_miss). The
GPU driver then faults the weights in through the same mapping, every
page a synchronous 4 KiB nfs_read_folio, about 1800 a second.
Read-around came back only when the GPU's walk happened to continue
through a window that one of the first hundred faults had read around:
async readahead restarted there, and about 900 hits later mmap_miss was
under the limit again. With the page cache cold, one model's first
picture took 700 s on 7.3.1, 512 s of it below 10 MB/s, against 239 s
on 6.18; a larger model's first run took 54 minutes against 13.

Is read-around meant to stay off for the life of the open file once the
limit is passed? I have no patch to offer.

#regzbot introduced: v7.1..v7.2

Thanks,
Trace

---8<--- mmap-ra.c
/*
 * mmap-ra.c: does a sparse first pass turn off mmap read-around for the
 * rest of an open file?
 *
 *   gcc -O2 -o mmap-ra mmap-ra.c && ./mmap-ra /path/on/a/disk/testfile
 *
 * Writes a 2600 MiB file (removed at the end), drops it from the page
 * cache with POSIX_FADV_DONTNEED, and counts major faults for a 64 MiB
 * sequential read through a private mapping.
 */
#define _GNU_SOURCE
#include <err.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/resource.h>
#include <unistd.h>

#define MIB	(1UL << 20)
#define SIZE	(2600 * MIB)
#define SPARSE	2000		/* single pages, 1 MiB apart */
#define SEQ_OFF	(2100 * MIB)
#define SEQ_LEN	(64 * MIB)

static long majflt(void)
{
	struct rusage ru;

	getrusage(RUSAGE_SELF, &ru);
	return ru.ru_majflt;
}

static char *open_map(const char *path, int *fd)
{
	char *m;

	*fd = open(path, O_RDONLY);
	if (*fd < 0)
		err(1, "open");
	m = mmap(NULL, SIZE, PROT_READ, MAP_PRIVATE, *fd, 0);
	if (m == MAP_FAILED)
		err(1, "mmap");
	return m;
}

static void run(const char *path, const char *name, int sparse, int advice,
		int reopen)
{
	long page = sysconf(_SC_PAGESIZE), before;
	volatile char sink;
	unsigned long off;
	char *m;
	int fd;

	fd = open(path, O_RDONLY);
	if (fd < 0)
		err(1, "open");
	if (posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED))
		errx(1, "posix_fadvise");
	close(fd);

	m = open_map(path, &fd);
	if (sparse)
		for (off = 0; off < SPARSE; off++)
			sink = m[off * MIB + 37 * page];
	if (advice && madvise(m, SIZE, advice))
		err(1, "madvise");
	if (reopen) {
		munmap(m, SIZE);
		close(fd);
		m = open_map(path, &fd);
	}

	before = majflt();
	for (off = SEQ_OFF; off < SEQ_OFF + SEQ_LEN; off += page)
		sink = m[off];
	printf("%-40s %6ld major faults\n", name, majflt() - before);

	(void)sink;
	munmap(m, SIZE);
	close(fd);
}

int main(int argc, char **argv)
{
	static char buf[MIB];
	unsigned long i;
	int fd;

	if (argc != 2)
		errx(2, "usage: %s FILE", argv[0]);

	fd = open(argv[1], O_WRONLY | O_CREAT | O_EXCL, 0600);
	if (fd < 0)
		err(1, "create");
	memset(buf, 0x5a, sizeof(buf));
	for (i = 0; i < SIZE / MIB; i++)
		if (write(fd, buf, MIB) != (ssize_t)MIB)
			err(1, "write");
	if (fsync(fd))
		err(1, "fsync");
	close(fd);

	setvbuf(stdout, NULL, _IOLBF, 0);
	run(argv[1], "sequential only", 0, 0, 0);
	run(argv[1], "sparse pass, then sequential", 1, 0, 0);
	run(argv[1], "sparse, MADV_SEQUENTIAL, sequential", 1, MADV_SEQUENTIAL, 0);
	run(argv[1], "sparse, close and reopen, sequential", 1, 0, 1);

	unlink(argv[1]);
	return 0;
}

[PATCH] mm/filemap: restart mmap readahead on sequential faults after many misses

[Gopal Malaviya]

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

Re: [PATCH] mm/filemap: restart mmap readahead on sequential faults after many misses

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [Medium] mm/filemap: do_sync_mmap_readahead() recovery fails when
  min_order > 0
- [Medium] mm/filemap: do_sync_mmap_readahead() ignores VM_RAND_READ and
  !ra_pages
- [Low] mm/filemap: prev_pos == -1 wraps to match pgoff 0 on 32-bit in
  mmap ra
It also noticed 1 related pre-existing issue this patch does not
introduce:
- [Medium] mm/readahead: unsigned underflow of index - start in
  page_cache_ra_order() [1]
--

commit 607714545f8f33b9040290a1fe8d984f2caffeba
Author: Gopal Malaviya <gopalmalaviya53@gmail.com>

mm/filemap: restart mmap readahead on sequential faults after many misses

When mmap_miss exceeds MMAP_LOTSAMISS in do_sync_mmap_readahead(), this
commit records the fault offset in ra->prev_pos and calls
page_cache_sync_ra() if the next fault miss lands on the immediately
following page, while clamping ra->mmap_miss to MMAP_LOTSAMISS * 10.

> diff --git a/mm/filemap.c b/mm/filemap.c
> index 371a4bbd06876..1548021472729 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;

[Severity: Low]
On 32-bit architectures, can a fault at vmf->pgoff == 0 match
vmf->pgoff - prev_index == 1 when ra->prev_pos is still -1?

file_ra_state_init() initializes ra->prev_pos to -1, and mmap faults while
mmap_miss <= MMAP_LOTSAMISS do not update it.  When the first fault with
mmap_miss > MMAP_LOTSAMISS lands on pgoff 0, truncating
(unsigned long long)ra->prev_pos >> PAGE_SHIFT to a 32-bit pgoff_t yields
prev_index = ULONG_MAX, so 0UL - ULONG_MAX == 1UL wraps around to true and
starts readahead on a non-sequential miss.

> +			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) {

[Severity: Medium]
Does this readahead recovery work when mapping_min_folio_order(mapping) > 0?

When the first miss above MMAP_LOTSAMISS returns without readahead,
filemap_fault() -> __filemap_get_folio_mpol() allocates a folio of
min_nrpages = mapping_min_folio_nrpages(mapping) base pages (at least 2).
During a sequential scan starting at a folio-aligned offset, the next cache
miss occurs at prev_index + min_nrpages, so vmf->pgoff - prev_index != 1 is
always true and readahead never starts.

Even if the initial miss was on the last base page of the previous folio so
that vmf->pgoff - prev_index == 1 holds, passing req_count = 1 instead of
mapping_min_folio_nrpages(mapping) to page_cache_sync_ra() sets mark =
index + 1 in page_cache_ra_order().  In ra_alloc_folio(),

mm/readahead.c:ra_alloc_folio() {
    ...
	mark = round_down(mark, 1UL << order);
	if (index == mark)
		folio_set_readahead(folio);
    ...
}

rounding mark down by 1UL << order places PG_readahead on the first
(faulting) folio instead of the next folio.  Because
maybe_unlock_mmap_for_io() drops mmap_lock, the retried fault runs with
FAULT_FLAG_TRIED set, skips do_async_mmap_readahead(), and maps that folio
via finish_fault(), so page_cache_async_ra() is never called to grow the
window.

[Severity: Medium]
When force_thp_readahead is true, can this block run page_cache_sync_ra()
even when VM_RAND_READ is set or ra->ra_pages is 0?

do_sync_mmap_readahead() only checks VM_RAND_READ and !ra->ra_pages when
!force_thp_readahead.  Once mmap_miss exceeds MMAP_LOTSAMISS on a
VM_HUGEPAGE VMA backed by a mapping with large folio support, two adjacent
misses reach this path: with VM_RAND_READ, page_cache_sync_ra() only checks
FMODE_RANDOM and issues multi-page sequential readahead while setting
PG_readahead on a folio that do_async_mmap_readahead() refuses to clear;
with !ra->ra_pages, maybe_unlock_mmap_for_io() drops mmap_lock and forces a
VM_FAULT_RETRY cycle only for page_cache_sync_ra() to do a single-page
forced read.

[Severity: Medium]
This problem wasn't introduced by this patch, but in page_cache_ra_order()
[1], can index - start underflow when an unaligned readahead request
fails on its first folio allocation?

mm/readahead.c:page_cache_ra_order() {
	pgoff_t start = readahead_index(ractl);
	pgoff_t index = start;
    ...
	ractl->_index = mapping_align_index(mapping, index);
	index = readahead_index(ractl);

	while (index <= limit) {
    ...
		err = ra_alloc_folio(ractl, index, mark, order, gfp);
		if (err)
			break;
		index += 1UL << order;
	}
    ...
fallback:
	if (ra->size > index - start)
		do_page_cache_ra(ractl, ra->size - (index - start),
				 ra->async_size);
}

On a mapping with mapping_min_folio_order(mapping) > 0, start holds the
unaligned readahead_index(ractl) before mapping_align_index() rounds index
down to a min_order boundary, making index < start.  If the first
ra_alloc_folio() call fails (for example with -EEXIST when a folio is
already cached at the aligned index), the loop breaks before advancing
index, so index - start wraps around near ULONG_MAX and skips the
do_page_cache_ra() fallback for the entire window.

[1] https://sashiko.dev/#/bug/linux-da6e8836-f808-4b39-9f04-de52995a0162

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109091444.128521-1-gopalmalaviya53@gmail.com?part=1

Re: [PATCH] mm/filemap: restart mmap readahead on sequential faults after many misses

[Jan Kara]

On Mon 09-11-26 09:14:44, Gopal Malaviya wrote:
> 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>

I think this [1] looks like a nicer solution to your problem.

[1] https://lore.kernel.org/all/20261109-mmap-miss-v1-1-8b44b33f3358@it.uu.se/

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] mm/filemap: restart mmap readahead on sequential faults after many misses

[Gopal Malaviya]

On Tue, Nov 10, 2026 at 09:15:49AM +0000, sashiko-bot@kernel.org wrote:
> - [Medium] mm/filemap: do_sync_mmap_readahead() recovery fails when
>   min_order > 0
> - [Medium] mm/filemap: do_sync_mmap_readahead() ignores VM_RAND_READ and
>   !ra_pages
> - [Low] mm/filemap: prev_pos == -1 wraps to match pgoff 0 on 32-bit in
>   mmap ra

Thanks, all three are right. On XFS with 16 KiB blocks the reproducer
still takes 4096 major faults with this patch, and on a MADV_HUGEPAGE
mapping with MADV_RANDOM it starts readahead anyway. I am testing a v2
that handles both and the 32-bit case, and will send it once the tests
are done.

The page_cache_ra_order() underflow is pre-existing; I will look at it
separately.

Re: [PATCH] mm/filemap: restart mmap readahead on sequential faults after many misses

[Gopal Malaviya]

On Tue 10-11-26 14:53:14, Jan Kara wrote:
> I think this [1] looks like a nicer solution to your problem.
>
> [1] https://lore.kernel.org/all/20261109-mmap-miss-v1-1-8b44b33f3358@it.uu.se/

Agreed, it is simpler. I am dropping this patch, so the v2 I mentioned
will not come. I have tested Alireza's patch with the reproducer from
Trace's report and replied in his thread.