Re: [PATCH] mm/readahead: use large folios in page_cache_ra_unbounded()

[Yuan-Hao Hsu <aa9736195201@gmail.com>]

On Tue, 15 Sep 2026 17:26:15 -0700, Andrew Morton wrote:
> Thanks, and welcome to Linux (I think?).

Thanks.  Yes, this is my first patch.

> Are any other filesystems affected by this change?

Every mapping with mapping_max_folio_order() above the minimum: ext4
(except the encrypt feature and data=journal), xfs, btrfs (except
HIGHMEM), erofs, nfs, afs, cifs, zonefs, f2fs immutable files, and the
block device page cache.  overlayfs follows the filesystem below it.

tmpfs sets the flag but cannot get here: force_page_cache_ra() returns
without read_folio/readahead a_ops, generic_fadvise() ignores hints on
a noop bdi, and madvise(MADV_WILLNEED) takes shmem_swapin_range().
fuse, gfs2, ubifs, ntfs3, ceph and 9p do not enable large folios.
Nothing changes with CONFIG_TRANSPARENT_HUGEPAGE=n.

v2 is tested on ext4, f2fs, xfs, btrfs, erofs, a block device, NFS and
cifs over loopback, and zonefs on a zoned null_blk; read() and mmap()
match the O_DIRECT sha256 of the file on each.  I could not set up
afs, but its ->readahead is netfs_readahead(), as used by cifs.

> This all sounds great, but I worry that the resulting increased
> consumption of larger-order pages will cause all sorts of unexpected
> mayhem to all sorts of unexpected things.

You are right, and v1 does exactly that.  __GFP_NORETRY on a costly
order still means an async compaction, a round of direct reclaim, a
second compaction and two kswapd wakeups before giving up, and v1
could pay that up to nine times per read().

Memory fragmented so that no block above order 3 remained, with the
remaining pages pinned so compaction could not help, 1024 x 1 MiB
pread() after POSIX_FADV_RANDOM from a RAM disk:

                              before       v1       v2
  sys ms                         219    1,462      239
  compact_stall                    0    2,437        0
  pgsteal_kswapd (pages)           0  234,494        0
  pswpout (pages)                  0   23,759        0
  folios left in the cache   262,144   36,508  260,869

v1 also made a plain sequential read() 3.6x slower there, through the
page_cache_ra_order() fallback into page_cache_ra_unbounded().

v2 allocates above the minimum order without __GFP_RECLAIM: it takes
a large folio when the free lists have one and never reclaims,
compacts or wakes kswapd to make one.  On the first failure the rest
of the request uses the minimum order, as page_cache_ra_order() does.
Keeping the reclaim flags but limiting it to one attempt per request
was not enough (543 ms, 67,183 pages reclaimed by kswapd): the gfp
mask is what matters, not the number of attempts.

> So for several reasons it's
>
> - allocate a large folio
> - check it
> - oops, can't use it, free it and retry with a smaller one

v2 scans the xarray first and sizes the folio to the absent run, so
filemap_add_folio() fails with -EEXIST only when another reader got
in between, and then the loop rescans instead of trying smaller
orders.  Four processes reading the same cold file after
POSIX_FADV_RANDOM, 64 KiB at a time, counted with a kretprobe:

  before  7,754 -EEXIST (one order-0 page each)
  v1     59,783
  v2     15,828

What is left is the race itself; the unpatched kernel sees the same
race at page granularity.  A memcg charge over the limit now fails
without reclaim and the request continues at the minimum order, the
path it takes today.

The setup and the numbers are in the v2 changelog.

Thanks,
Yuan-Hao Hsu