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

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 15 Sep 2026 21:59:09 +0800 Yuan-Hao Hsu <aa9736195201@gmail.com> wrote:

Thanks, and welcome to Linux (I think?).

> Forced readahead still allocates one folio per page.  Everything that
> reaches page_cache_ra_unbounded() gets mapping_min_folio_order()
> folios, which is order 0 on ext4, xfs and btrfs:

Are any other filesystems affected by this change?

> 
> ...
> 
> Allocate the largest folio that fits instead
>

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.

: bounded by the mapping's
> maximum order, by what is left of the request and by the alignment of
> the index, never below the minimum order.  Nothing beyond the request is
> read; for a forced read the request is exactly what the caller asked
> for.  If an allocation fails, or filemap_add_folio() returns -ENOMEM,
> do not ask for that order again during this request.  If
> filemap_add_folio() returns -EEXIST for a large folio, something sits
> within the range it would cover but the index itself may still be free,
> so retry with a smaller folio and only skip the index once the minimum
> size collides, as before.  ra_alloc_folio() already does the
> allocation, the PG_readahead mark and the accounting for
> page_cache_ra_order(); move it up unchanged and use it here too, so
> the mark goes on the folio that contains the mark index in both
> places.

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

People do all sorts of strange things and this alone could cause
meltdowns which we don't get to hear about for two years.

So the change seems quite logical but right now, I don't know how to
move ahead with it :(.  What do others think?