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

On Mon,  1 Jun 2026 03:21:16 -0700 Usama Arif [off-list ref] wrote:

Hopefully this is the last revision. The only change from the previous
revision is that the logic for deciding THP order was simplified and
the max is now capped to 2M. Thanks Pedro and Jan for the suggestion
and the dicusssion!

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

The patches are on top of mm-unstable from 28 May
(8a74e22643189e0ae339afc91110ddb4cab1941b) which include patch [1]
that make mmap_miss accounting symmetric for VM_SEQ_READ which was pointed
out by sashiko in the previous revision.

We lost the [0/N] cover letter.  Please do retain (and maintain!) that
across revisions.  I used the one from the v6 patchset.

v6 -> v7: https://lore.kernel.org/all/20260528165635.2068012-1-usama.arif@linux.dev/ (local)
- Simplify logic and just cap the max THP order to 2M (Pedro and Jan)

Here's how v7 altered mm.git:


 mm/filemap.c |   15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

--- a/mm/filemap.c~b
+++ a/mm/filemap.c

@@ -3320,17 +3320,12 @@ static struct file *do_sync_mmap_readahe
 	/* Use the readahead code, even if readahead is disabled */
 	if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && (vm_flags & VM_HUGEPAGE)) {
 		/*
-		 * Preserve PMD-sized readahead where it already fits in
-		 * the page cache. Otherwise cap the new fallback path at
-		 * 2MB: this is the common PMD-sized hugepage size, and it
-		 * avoids memory pressure from very large forced readahead
-		 * when mapping_max_folio_order() is high (for example,
-		 * 128MB with 64K base pages on arm64).
+		 * Cap max THP order at 2MB: this is the common PMD-sized
+		 * hugepage size, and it avoids memory pressure from very
+		 * large forced readahead when mapping_max_folio_order() is
+		 * high (for example, 128MB with 64K base pages on arm64).
 		 */
-		if (HPAGE_PMD_ORDER <= MAX_PAGECACHE_ORDER) {
-			force_thp_readahead = true;
-			thp_order = HPAGE_PMD_ORDER;
-		} else if (mapping_large_folio_support(mapping)) {
+		if (mapping_large_folio_support(mapping)) {
 			force_thp_readahead = true;
 			thp_order = min_t(unsigned int,
 					  mapping_max_folio_order(mapping),

_