Re: [PATCH v5 0/2] mm: improve large folio readahead for exec memory

[Usama Arif <usama.arif@linux.dev>]

On 22/05/2026 20:20, Andrew Morton wrote:
> On Fri, 22 May 2026 09:23:46 -0700 Usama Arif <usama.arif@linux.dev> wrote:
> 
>> Two checks in do_sync_mmap_readahead() limit large-folio readahead:
>>
>>   1. The mmap_miss heuristic is meant to throttle wasteful speculative
>>      readahead. It is currently also applied to the VM_EXEC readahead
>>      path, which is targeted rather than speculative. Once mmap_miss exceeds
>>      MMAP_LOTSAMISS, exec readahead - including the large-folio
>>      order requested by exec_folio_order() - is disabled. On
>>      configurations where the mmap_miss decrement paths are not
>>      active (see patch 1) the counter only grows, so exec readahead
>>      is permanently disabled after the first 100 faults.
>>
>>   2. The force_thp_readahead path is gated only on
>>      HPAGE_PMD_ORDER <= MAX_PAGECACHE_ORDER and always drives the
>>      readahead at HPAGE_PMD_ORDER. Configurations where
>>      HPAGE_PMD_ORDER exceeds MAX_PAGECACHE_ORDER never reach this
>>      path, even when the mapping itself supports usefully large
>>      folios well below the cap.
>>
>> Both issues are most visible on arm64 with a 64K base page size,
>> where HPAGE_PMD_ORDER is 13 (512MB) -- above MAX_PAGECACHE_ORDER
>> (11) -- and where fault_around_pages collapses to 1 disabling
>> should_fault_around() (one of the two mmap_miss decrement sites).
>> However the fixes are architecture-agnostic: patch 1 reflects the
>> nature of VM_EXEC readahead regardless of base page size, and
>> patch 2 generalises the gate so any mapping advertising a usefully
>> large maximum folio order can benefit.
>>
>> I created a benchmark that mmaps a large executable file and calls
>> RET-stub functions at PAGE_SIZE offsets across it. "Cold" measures
>> fault + readahead cost. "Random" first faults in all pages with a
>> sequential sweep (not measured), then measures time for calling random
>> offsets, isolating iTLB miss cost for scattered execution.
>>
>> The benchmark results on Neoverse V2 (Grace), arm64 with 64K base pages,
>> 512MB executable file on ext4, averaged over 3 runs:
>>
>>   Phase      | Baseline     | Patched      | Improvement
>>   -----------|--------------|--------------|------------------
>>   Cold fault | 83.4 ms      | 41.3 ms      | 50% faster
>>   Random     | 76.0 ms      | 58.3 ms      | 23% faster
> 
> Well that's nice.
> 
> AI review might have found a few things:
> 	https://sashiko.dev/#/patchset/20260522162422.3856502-1-usama.arif@linux.dev
> 

Thanks Andrew! So sashiko seems to have brought out some interesting problems,
some of which are pre-existing. For example, the decrement sites for mmap_miss
in do_async_mmap_readahead() and filemap_map_pages() dont skip for VM_SEQ_READ.

I have sent this as an independent patch in [1].

I will send the next version of this series on top of [1] in a few days
addressing the rest of the issues raised by sashiko.

[1] https://lore.kernel.org/all/20260525145751.2671248-1-usama.arif@linux.dev/