RE:(2) [PATCH] mm/readahead: keep at least half of the async window when aligning it

[Daejun Park]

On Mon, Nov 02, 2026 at 10:46:53PM +0100, Jan Kara wrote:
> OK, I can see how it easily happens once that we trim the readahead
> significantly due to alignment. I'm not fully clear how it happens
> periodically. Is it that you do 1 MiB misaligned reads and so we
> periodically end up triggering async readahead from positions that are
> not aligned to the current value of ra->order?
[...]
> Instead of trying to second-guess the logic of page_cache_ra_order()
> in page_cache_async_ra() I think we could pass a flag to it in ractl
> telling it it's allowed to shrink the window instead of allocating
> small folios and then handle the alignment in page_cache_ra_order().
> Hum?

Thanks, agreed. v2 will pass a flag in struct readahead_control and
align the window end in page_cache_ra_order() after clamping new_order.
When a window still starts just below a 1UL << new_order boundary, v2
steps new_order down until the trim keeps at least half of the window.

Your diagnosis of the periodic trim matches the trace:

1. After the 4 KiB read, the window at page 48 has size 56 (ilog2 = 5)
   while ra->order is 6. Aligning to 64 before clamping to ilog2(56)
   trims [48, 104) to 16 pages.

2. Because of that trim, ra->size is only 64 near the end of the 1 MiB
   read, where the remaining req_count is 81. get_next_ra_size(64, 81)
   sets ra->size = 81, and ffs(81) - 1 = 0 skips alignment.

3. That enters a 13-window cycle every two 1 MiB reads (sizes 64, 81,
   63, 126, 2, 4, 8, 16, 32, 64, 4, 16, 32), where [896, 1022) leaves
   the next 128-page window at page 1022 and trims it to 2 pages.

Tested on mm-new in QEMU (XFS on NVMe, read_ahead_kb=128, cold cache),
reading a 512 MiB file after a 4 KiB read at offset 0 (5-run median):

- max_sectors_kb=512, 1 MiB reads: mm-new issues 3329 reads in 0.251 s
  with 9721 folios (0 of order 7). v2 issues 1031 reads in 0.200 s with
  1039 folios (1021 of order 7).

- max_sectors_kb=1024 or 2048, 1 MiB reads: mm-new and v1 allocate 2839
  folios (766 of order 7) as ffs(255) - 1 = 0 skips alignment. v2
  allocates 1039 folios (1021 of order 7).

- max_sectors_kb=2048, 3 MiB reads: v1 issued 348 reads with 0 order-9
  folios as ffs(385) - 1 = 0 skipped alignment. v2 issues 265 reads
  (273 on mm-new) with 252 order-9 folios out of 277.

Daejun