From: Usama Arif <usama.arif@linux.dev>
To: Andrew Morton <akpm@linux-foundation.org>,
david@kernel.org, willy@infradead.org, ryan.roberts@arm.com,
linux-mm@kvack.org
Cc: r@hev.cc, jack@suse.cz,
Andrew Donnellan <andrew+kernel@donnellan.id.au>,
apopple@nvidia.com, baohua@kernel.org,
baolin.wang@linux.alibaba.com, brauner@kernel.org,
catalin.marinas@arm.com, dev.jain@arm.com, kees@kernel.org,
kevin.brodsky@arm.com, lance.yang@linux.dev,
Liam R.Howlett <liam@infradead.org>,
linux-arm-kernel@lists.infradead.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
ljs@kernel.org, mhocko@suse.com, npache@redhat.com,
pasha.tatashin@soleen.com, rmclure@linux.ibm.com,
rppt@kernel.org, surenb@google.com, vbabka@kernel.org,
Al Viro <viro@zeniv.linux.org.uk>,
wilts.infradead.org@kvack.org,
"linux-fsdevel@vger.kernel.l"@kernel.org, ziy@nvidia.com,
hannes@cmpxchg.org, kas@kernel.org, shakeel.butt@linux.dev,
kernel-team@meta.com, Usama Arif <usama.arif@linux.dev>
Subject: [PATCH v6 2/2] mm: use mapping_max_folio_order() for force_thp_readahead order
Date: Thu, 28 May 2026 09:55:20 -0700 [thread overview]
Message-ID: <20260528165635.2068012-3-usama.arif@linux.dev> (raw)
In-Reply-To: <20260528165635.2068012-1-usama.arif@linux.dev>
The force_thp_readahead path in do_sync_mmap_readahead() is gated on
HPAGE_PMD_ORDER <= MAX_PAGECACHE_ORDER and always requests
HPAGE_PMD_ORDER / HPAGE_PMD_NR. On configurations where HPAGE_PMD_ORDER
exceeds MAX_PAGECACHE_ORDER, notably arm64 with a 64K base page size,
VM_HUGEPAGE mappings cannot use this path and fall back to the non-forced
mmap readahead path even when the mapping supports useful large folios.
Keep the existing PMD-sized behavior when HPAGE_PMD_ORDER fits in the
page cache. When it does not, enable forced readahead for mappings that
support large folios and request an order capped by both
mapping_max_folio_order(mapping) and 2MB.
2MB is chosen as the cap because it matches the PMD size on x86_64
and on arm64 with 4K or 16K base pages, so the size/memory-pressure
tradeoff for folios of that size is already well understood. On arm64
with a 64K base page size, 2MB is also the contiguous-PTE (contpte)
block size, so the resulting folios coalesce into a single TLB entry
and reduce TLB pressure on the readahead path.
The final allocation order may still be clamped by page_cache_ra_order()
to the mapping and request geometry, but this gives VM_HUGEPAGE mappings
on such configurations a large-folio readahead request instead of
dropping back to base-page readahead.
Signed-off-by: Usama Arif <usama.arif@linux.dev>
---
mm/filemap.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index a16b33e0fc71..bfb891d9da1f 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -3312,14 +3312,23 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf)
struct file *fpin = NULL;
vm_flags_t vm_flags = vmf->vma->vm_flags;
bool force_thp_readahead = false;
+ unsigned int thp_order = 0;
unsigned short mmap_miss;
ractl._max_index = vmf->vma->vm_pgoff + vma_pages(vmf->vma) - 1;
/* Use the readahead code, even if readahead is disabled */
- if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) &&
- (vm_flags & VM_HUGEPAGE) && HPAGE_PMD_ORDER <= MAX_PAGECACHE_ORDER)
- force_thp_readahead = true;
+ if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && (vm_flags & VM_HUGEPAGE)) {
+ if (HPAGE_PMD_ORDER <= MAX_PAGECACHE_ORDER) {
+ force_thp_readahead = true;
+ thp_order = HPAGE_PMD_ORDER;
+ } else if (mapping_large_folio_support(mapping)) {
+ force_thp_readahead = true;
+ thp_order = min_t(unsigned int,
+ mapping_max_folio_order(mapping),
+ get_order(SZ_2M));
+ }
+ }
if (!force_thp_readahead) {
/*
@@ -3354,17 +3363,19 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf)
}
if (force_thp_readahead) {
+ unsigned long folio_nr_pages = 1UL << thp_order;
+
fpin = maybe_unlock_mmap_for_io(vmf, fpin);
- ractl._index &= ~((unsigned long)HPAGE_PMD_NR - 1);
- ra->size = HPAGE_PMD_NR;
+ ractl._index &= ~(folio_nr_pages - 1);
+ ra->size = folio_nr_pages;
/*
- * Fetch two PMD folios, so we get the chance to actually
+ * Fetch two folios so we get the chance to actually
* readahead, unless we've been told not to.
*/
if (!(vm_flags & VM_RAND_READ))
ra->size *= 2;
- ra->async_size = HPAGE_PMD_NR;
- ra->order = HPAGE_PMD_ORDER;
+ ra->async_size = folio_nr_pages;
+ ra->order = thp_order;
page_cache_ra_order(&ractl, ra);
return fpin;
}
--
2.52.0
WARNING: multiple messages have this Message-ID (diff)
From: Usama Arif <usama.arif@linux.dev>
To: Andrew Morton <akpm@linux-foundation.org>,
david@kernel.org, willy@infradead.org, ryan.roberts@arm.com,
linux-mm@kvack.org
Cc: r@hev.cc, jack@suse.cz,
Andrew Donnellan <andrew+kernel@donnellan.id.au>,
apopple@nvidia.com, baohua@kernel.org,
baolin.wang@linux.alibaba.com, brauner@kernel.org,
catalin.marinas@arm.com, dev.jain@arm.com, kees@kernel.org,
kevin.brodsky@arm.com, lance.yang@linux.dev,
Liam R. Howlett <liam@infradead.org>,
linux-arm-kernel@lists.infradead.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
ljs@kernel.org, mhocko@suse.com, npache@redhat.com,
pasha.tatashin@soleen.com, rmclure@linux.ibm.com,
rppt@kernel.org, surenb@google.com, vbabka@kernel.org,
Al Viro <viro@zeniv.linux.org.uk>,
wilts.infradead.org, linux-fsdevel@vger.kernel.l@kernel.org,
ziy@nvidia.com, hannes@cmpxchg.org, kas@kernel.org,
shakeel.butt@linux.dev, kernel-team@meta.com,
Usama Arif <usama.arif@linux.dev>
Subject: [PATCH v6 2/2] mm: use mapping_max_folio_order() for force_thp_readahead order
Date: Thu, 28 May 2026 09:55:20 -0700 [thread overview]
Message-ID: <20260528165635.2068012-3-usama.arif@linux.dev> (raw)
In-Reply-To: <20260528165635.2068012-1-usama.arif@linux.dev>
The force_thp_readahead path in do_sync_mmap_readahead() is gated on
HPAGE_PMD_ORDER <= MAX_PAGECACHE_ORDER and always requests
HPAGE_PMD_ORDER / HPAGE_PMD_NR. On configurations where HPAGE_PMD_ORDER
exceeds MAX_PAGECACHE_ORDER, notably arm64 with a 64K base page size,
VM_HUGEPAGE mappings cannot use this path and fall back to the non-forced
mmap readahead path even when the mapping supports useful large folios.
Keep the existing PMD-sized behavior when HPAGE_PMD_ORDER fits in the
page cache. When it does not, enable forced readahead for mappings that
support large folios and request an order capped by both
mapping_max_folio_order(mapping) and 2MB.
2MB is chosen as the cap because it matches the PMD size on x86_64
and on arm64 with 4K or 16K base pages, so the size/memory-pressure
tradeoff for folios of that size is already well understood. On arm64
with a 64K base page size, 2MB is also the contiguous-PTE (contpte)
block size, so the resulting folios coalesce into a single TLB entry
and reduce TLB pressure on the readahead path.
The final allocation order may still be clamped by page_cache_ra_order()
to the mapping and request geometry, but this gives VM_HUGEPAGE mappings
on such configurations a large-folio readahead request instead of
dropping back to base-page readahead.
Signed-off-by: Usama Arif <usama.arif@linux.dev>
---
mm/filemap.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index a16b33e0fc71..bfb891d9da1f 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -3312,14 +3312,23 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf)
struct file *fpin = NULL;
vm_flags_t vm_flags = vmf->vma->vm_flags;
bool force_thp_readahead = false;
+ unsigned int thp_order = 0;
unsigned short mmap_miss;
ractl._max_index = vmf->vma->vm_pgoff + vma_pages(vmf->vma) - 1;
/* Use the readahead code, even if readahead is disabled */
- if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) &&
- (vm_flags & VM_HUGEPAGE) && HPAGE_PMD_ORDER <= MAX_PAGECACHE_ORDER)
- force_thp_readahead = true;
+ if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && (vm_flags & VM_HUGEPAGE)) {
+ if (HPAGE_PMD_ORDER <= MAX_PAGECACHE_ORDER) {
+ force_thp_readahead = true;
+ thp_order = HPAGE_PMD_ORDER;
+ } else if (mapping_large_folio_support(mapping)) {
+ force_thp_readahead = true;
+ thp_order = min_t(unsigned int,
+ mapping_max_folio_order(mapping),
+ get_order(SZ_2M));
+ }
+ }
if (!force_thp_readahead) {
/*
@@ -3354,17 +3363,19 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf)
}
if (force_thp_readahead) {
+ unsigned long folio_nr_pages = 1UL << thp_order;
+
fpin = maybe_unlock_mmap_for_io(vmf, fpin);
- ractl._index &= ~((unsigned long)HPAGE_PMD_NR - 1);
- ra->size = HPAGE_PMD_NR;
+ ractl._index &= ~(folio_nr_pages - 1);
+ ra->size = folio_nr_pages;
/*
- * Fetch two PMD folios, so we get the chance to actually
+ * Fetch two folios so we get the chance to actually
* readahead, unless we've been told not to.
*/
if (!(vm_flags & VM_RAND_READ))
ra->size *= 2;
- ra->async_size = HPAGE_PMD_NR;
- ra->order = HPAGE_PMD_ORDER;
+ ra->async_size = folio_nr_pages;
+ ra->order = thp_order;
page_cache_ra_order(&ractl, ra);
return fpin;
}
--
2.52.0
next prev parent reply other threads:[~2026-05-28 16:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 16:55 [PATCH v6 0/2] mm: improve large folio readahead for exec memory Usama Arif
2026-05-28 16:55 ` Usama Arif
2026-05-28 16:55 ` [PATCH v6 1/2] mm: bypass mmap_miss heuristic for VM_EXEC readahead Usama Arif
2026-05-28 16:55 ` Usama Arif
2026-05-29 9:47 ` Pedro Falcato
2026-05-28 16:55 ` Usama Arif [this message]
2026-05-28 16:55 ` [PATCH v6 2/2] mm: use mapping_max_folio_order() for force_thp_readahead order Usama Arif
2026-05-29 10:01 ` Pedro Falcato
2026-05-29 12:19 ` Usama Arif
2026-05-29 13:40 ` Pedro Falcato
2026-05-29 14:11 ` Usama Arif
2026-05-30 15:16 ` Jan Kara
2026-06-01 9:43 ` Usama Arif
2026-06-02 17:35 ` Pedro Falcato
2026-06-03 10:10 ` Usama Arif
2026-06-03 11:51 ` Pedro Falcato
2026-06-02 17:46 ` Pedro Falcato
2026-05-29 12:36 ` Usama Arif
2026-05-28 20:27 ` [PATCH v6 0/2] mm: improve large folio readahead for exec memory Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260528165635.2068012-3-usama.arif@linux.dev \
--to=usama.arif@linux.dev \
--cc="linux-fsdevel@vger.kernel.l"@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andrew+kernel@donnellan.id.au \
--cc=apopple@nvidia.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=brauner@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=kas@kernel.org \
--cc=kees@kernel.org \
--cc=kernel-team@meta.com \
--cc=kevin.brodsky@arm.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=npache@redhat.com \
--cc=pasha.tatashin@soleen.com \
--cc=r@hev.cc \
--cc=rmclure@linux.ibm.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=wilts.infradead.org@kvack.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.