hugepage_global_enabled() and hugepage_global_always() only exist
when CONFIG_TRANSPARENT_HUGEPAGE is set. Add inline stubs that
return false to let code compile when THP is disabled.
Signed-off-by: WANG Rui <r@hev.cc>
---
include/linux/huge_mm.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index a4d9f964dfde..badeebd4ea98 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -570,6 +570,16 @@ void map_anon_folio_pmd_nopf(struct folio *folio, pmd_t *pmd,
#else /* CONFIG_TRANSPARENT_HUGEPAGE */
+static inline bool hugepage_global_enabled(void)
+{
+ return false;
+}
+
+static inline bool hugepage_global_always(void)
+{
+ return false;
+}
+
static inline bool folio_test_pmd_mappable(struct folio *folio)
{
return false;
--
2.53.0On 3/10/26 04:11, WANG Rui wrote:
> hugepage_global_enabled() and hugepage_global_always() only exist
> when CONFIG_TRANSPARENT_HUGEPAGE is set. Add inline stubs that
> return false to let code compile when THP is disabled.
>
> Signed-off-by: WANG Rui <r@hev.cc>
> ---
> include/linux/huge_mm.h | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index a4d9f964dfde..badeebd4ea98 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -570,6 +570,16 @@ void map_anon_folio_pmd_nopf(struct folio *folio, pmd_t *pmd,
>
> #else /* CONFIG_TRANSPARENT_HUGEPAGE */
>
> +static inline bool hugepage_global_enabled(void)
> +{
> + return false;
> +}
> +
> +static inline bool hugepage_global_always(void)
> +{
> + return false;
> +}
> +
> static inline bool folio_test_pmd_mappable(struct folio *folio)
> {
> return false;
There are other ways to enable PMD THP. So I don't quite think this is
the right tool for the job.
--
Cheers,
David
On 3/12/26 16:53, David Hildenbrand (Arm) wrote:
> On 3/10/26 04:11, WANG Rui wrote:
>> hugepage_global_enabled() and hugepage_global_always() only exist
>> when CONFIG_TRANSPARENT_HUGEPAGE is set. Add inline stubs that
>> return false to let code compile when THP is disabled.
>>
>> Signed-off-by: WANG Rui <r@hev.cc>
>> ---
>> include/linux/huge_mm.h | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>> index a4d9f964dfde..badeebd4ea98 100644
>> --- a/include/linux/huge_mm.h
>> +++ b/include/linux/huge_mm.h
>> @@ -570,6 +570,16 @@ void map_anon_folio_pmd_nopf(struct folio *folio, pmd_t *pmd,
>>
>> #else /* CONFIG_TRANSPARENT_HUGEPAGE */
>>
>> +static inline bool hugepage_global_enabled(void)
>> +{
>> + return false;
>> +}
>> +
>> +static inline bool hugepage_global_always(void)
>> +{
>> + return false;
>> +}
>> +
>> static inline bool folio_test_pmd_mappable(struct folio *folio)
>> {
>> return false;
>
> There are other ways to enable PMD THP. So I don't quite think this is
> the right tool for the job.
Ah, you care about file THPs ... gah.
Why can't we simply do the alignment without considering the current
setting?
--
Cheers,
David
Hi David,
On Thu, Mar 12, 2026 at 11:57 PM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 3/12/26 16:53, David Hildenbrand (Arm) wrote:
> > On 3/10/26 04:11, WANG Rui wrote:
> >> hugepage_global_enabled() and hugepage_global_always() only exist
> >> when CONFIG_TRANSPARENT_HUGEPAGE is set. Add inline stubs that
> >> return false to let code compile when THP is disabled.
> >>
> >> Signed-off-by: WANG Rui <r@hev.cc>
> >> ---
> >> include/linux/huge_mm.h | 10 ++++++++++
> >> 1 file changed, 10 insertions(+)
> >>
> >> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> >> index a4d9f964dfde..badeebd4ea98 100644
> >> --- a/include/linux/huge_mm.h
> >> +++ b/include/linux/huge_mm.h
> >> @@ -570,6 +570,16 @@ void map_anon_folio_pmd_nopf(struct folio *folio, pmd_t *pmd,
> >>
> >> #else /* CONFIG_TRANSPARENT_HUGEPAGE */
> >>
> >> +static inline bool hugepage_global_enabled(void)
> >> +{
> >> + return false;
> >> +}
> >> +
> >> +static inline bool hugepage_global_always(void)
> >> +{
> >> + return false;
> >> +}
> >> +
> >> static inline bool folio_test_pmd_mappable(struct folio *folio)
> >> {
> >> return false;
> >
> > There are other ways to enable PMD THP. So I don't quite think this is
> > the right tool for the job.
>
> Ah, you care about file THPs ... gah.
>
> Why can't we simply do the alignment without considering the current
> setting?
The main motivation of raising the alignment here is to increase the
chance of getting PMD-sized THPs for executable mappings.
If THP is not in "always" mode, the kernel will not automatically
collapse file-backed mappings into THPs, so the increased alignment
would not actually improve THP usage.
In that case we would only be introducing additional padding in the
virtual address layout, which slightly reduces ASLR entropy without
providing a practical benefit.
That's why the current code limits this to the "always" mode.
Thanks,
Rui
On 3/12/26 17:12, hev wrote:
> Hi David,
>
> On Thu, Mar 12, 2026 at 11:57 PM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
>>
>> On 3/12/26 16:53, David Hildenbrand (Arm) wrote:
>>>
>>> There are other ways to enable PMD THP. So I don't quite think this is
>>> the right tool for the job.
>>
>> Ah, you care about file THPs ... gah.
>>
>> Why can't we simply do the alignment without considering the current
>> setting?
>
> The main motivation of raising the alignment here is to increase the
> chance of getting PMD-sized THPs for executable mappings.
>
> If THP is not in "always" mode, the kernel will not automatically
> collapse file-backed mappings into THPs, so the increased alignment
> would not actually improve THP usage.
>
> In that case we would only be introducing additional padding in the
> virtual address layout, which slightly reduces ASLR entropy without
> providing a practical benefit.
Well, that parameter can get toggled at runtime later? Also, I think
that readahead code could end up allocating a PMD THP (I might be
wrong about that, the code is confusing).
Let's take a look at __get_unmapped_area(), where we don't care about
ASLR entropy for anonymous memory:
} else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && !file
&& !addr /* no hint */
&& IS_ALIGNED(len, PMD_SIZE)) {
Interestingly we had:
commit 34d7cf637c437d5c2a8a6ef23ea45193bad8a91c
Author: Kefeng Wang <wangkefeng.wang@huawei.com>
Date: Fri Dec 6 15:03:45 2024 +0800
mm: don't try THP alignment for FS without get_unmapped_area
Commit ed48e87c7df3 ("thp: add thp_get_unmapped_area_vmflags()") changes
thp_get_unmapped_area() to thp_get_unmapped_area_vmflags() in
__get_unmapped_area(), which doesn't initialize local get_area for
anonymous mappings. This leads to us always trying THP alignment even for
file_operations which have a NULL ->get_unmapped_area() callback.
Since commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
boundaries") we only want to enable THP alignment for anonymous mappings,
so add a !file check to avoid attempting THP alignment for file mappings.
Found issue by code inspection. THP alignment is used for easy or more
pmd mappings, from vma side. This may cause unnecessary VMA fragmentation
and potentially worse performance on filesystems that do not actually
support THPs and thus cannot benefit from the alignment.
I'm not sure about the "VMA fragmentation" argument, really. We only consider
stuff that is already multiples of PMD_SIZE.
Filesystem support for THPs is also not really something you would handle, and it's
a problem that solves itself over time as more filesystems keep adding support for
large folios.
So I think we should try limiting it to IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE),
but not checking the runtime toggle.
--
Cheers,
David
On 2026/3/13 00:29, David Hildenbrand (Arm) wrote:
> On 3/12/26 17:12, hev wrote:
>> Hi David,
>>
>> On Thu, Mar 12, 2026 at 11:57 PM David Hildenbrand (Arm)
>> <david@kernel.org> wrote:
>>>
>>> On 3/12/26 16:53, David Hildenbrand (Arm) wrote:
>>>>
>>>> There are other ways to enable PMD THP. So I don't quite think this is
>>>> the right tool for the job.
>>>
>>> Ah, you care about file THPs ... gah.
>>>
>>> Why can't we simply do the alignment without considering the current
>>> setting?
>>
>> The main motivation of raising the alignment here is to increase the
>> chance of getting PMD-sized THPs for executable mappings.
>>
>> If THP is not in "always" mode, the kernel will not automatically
>> collapse file-backed mappings into THPs, so the increased alignment
>> would not actually improve THP usage.
>>
>> In that case we would only be introducing additional padding in the
>> virtual address layout, which slightly reduces ASLR entropy without
>> providing a practical benefit.
>
> Well, that parameter can get toggled at runtime later? Also, I think
> that readahead code could end up allocating a PMD THP (I might be
> wrong about that, the code is confusing).
Right. In do_sync_mmap_readahead(), if the VMA has VM_HUGEPAGE,
force_thp_readahead becomes true and ra->order is set to
HPAGE_PMD_ORDER, IIUC.
/* 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;
That order is then passed down to page_cache_ra_order() and finally to
filemap_alloc_folio().
if (force_thp_readahead) {
[...]
ra->async_size = HPAGE_PMD_NR;
ra->order = HPAGE_PMD_ORDER;
page_cache_ra_order(&ractl, ra);
return fpin;
}
For plain VM_EXEC, the code starts from exec_folio_order(), not
HPAGE_PMD_ORDER.
if (vm_flags & VM_EXEC) {
[...]
ra->order = exec_folio_order();
[...]
ra->async_size = 0;
}
The default exec_folio_order() is small, and arm64 only overrides it
to 64K.
/*
* Request exec memory is read into pagecache in at least 64K folios.
This size
* can be contpte-mapped when 4K base pages are in use (16 pages into 1
iTLB
* entry), and HPA can coalesce it (4 pages into 1 TLB entry) when 16K base
* pages are in use.
*/
#define exec_folio_order() ilog2(SZ_64K >> PAGE_SHIFT)
>
> Let's take a look at __get_unmapped_area(), where we don't care about
> ASLR entropy for anonymous memory:
>
> } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && !file
> && !addr /* no hint */
> && IS_ALIGNED(len, PMD_SIZE)) {
Yeah. For anonymous memory, the kernel is willing to do THP-friendly
alignment, but it is constrained, of course :)
> Interestingly we had:
>
> commit 34d7cf637c437d5c2a8a6ef23ea45193bad8a91c
> Author: Kefeng Wang <wangkefeng.wang@huawei.com>
> Date: Fri Dec 6 15:03:45 2024 +0800
>
> mm: don't try THP alignment for FS without get_unmapped_area
>
> Commit ed48e87c7df3 ("thp: add thp_get_unmapped_area_vmflags()") changes
> thp_get_unmapped_area() to thp_get_unmapped_area_vmflags() in
> __get_unmapped_area(), which doesn't initialize local get_area for
> anonymous mappings. This leads to us always trying THP alignment even for
> file_operations which have a NULL ->get_unmapped_area() callback.
>
> Since commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
> boundaries") we only want to enable THP alignment for anonymous mappings,
> so add a !file check to avoid attempting THP alignment for file mappings.
>
> Found issue by code inspection. THP alignment is used for easy or more
> pmd mappings, from vma side. This may cause unnecessary VMA fragmentation
> and potentially worse performance on filesystems that do not actually
> support THPs and thus cannot benefit from the alignment.
Looks like this commit does not *ban* file-backed THP-friendly alignment
completely. It only prevents file mappings from getting it accidentally
via the generic fallback path.
Note that some filesystems still explicitly opt in with their own
.get_unmapped_area = thp_get_unmapped_area
for example ext4, xfs, and btrfs.
So explicit filesystem opt-in is still allowed :)
> I'm not sure about the "VMA fragmentation" argument, really. We only consider
> stuff that is already multiples of PMD_SIZE.
>
> Filesystem support for THPs is also not really something you would handle, and it's
> a problem that solves itself over time as more filesystems keep adding support for
> large folios.
>
> So I think we should try limiting it to IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE),
> but not checking the runtime toggle.
Good point! ELF layout is decided once at exec time, while the runtime
THP mode
can change later.
On Fri, Mar 13, 2026 at 12:29 AM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 3/12/26 17:12, hev wrote:
> > Hi David,
> >
> > On Thu, Mar 12, 2026 at 11:57 PM David Hildenbrand (Arm)
> > <david@kernel.org> wrote:
> >>
> >> On 3/12/26 16:53, David Hildenbrand (Arm) wrote:
> >>>
> >>> There are other ways to enable PMD THP. So I don't quite think this is
> >>> the right tool for the job.
> >>
> >> Ah, you care about file THPs ... gah.
> >>
> >> Why can't we simply do the alignment without considering the current
> >> setting?
> >
> > The main motivation of raising the alignment here is to increase the
> > chance of getting PMD-sized THPs for executable mappings.
> >
> > If THP is not in "always" mode, the kernel will not automatically
> > collapse file-backed mappings into THPs, so the increased alignment
> > would not actually improve THP usage.
> >
> > In that case we would only be introducing additional padding in the
> > virtual address layout, which slightly reduces ASLR entropy without
> > providing a practical benefit.
>
> Well, that parameter can get toggled at runtime later? Also, I think
> that readahead code could end up allocating a PMD THP (I might be
> wrong about that, the code is confusing).
>
> Let's take a look at __get_unmapped_area(), where we don't care about
> ASLR entropy for anonymous memory:
>
> } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && !file
> && !addr /* no hint */
> && IS_ALIGNED(len, PMD_SIZE)) {
>
> Interestingly we had:
>
> commit 34d7cf637c437d5c2a8a6ef23ea45193bad8a91c
> Author: Kefeng Wang <wangkefeng.wang@huawei.com>
> Date: Fri Dec 6 15:03:45 2024 +0800
>
> mm: don't try THP alignment for FS without get_unmapped_area
>
> Commit ed48e87c7df3 ("thp: add thp_get_unmapped_area_vmflags()") changes
> thp_get_unmapped_area() to thp_get_unmapped_area_vmflags() in
> __get_unmapped_area(), which doesn't initialize local get_area for
> anonymous mappings. This leads to us always trying THP alignment even for
> file_operations which have a NULL ->get_unmapped_area() callback.
>
> Since commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP
> boundaries") we only want to enable THP alignment for anonymous mappings,
> so add a !file check to avoid attempting THP alignment for file mappings.
>
> Found issue by code inspection. THP alignment is used for easy or more
> pmd mappings, from vma side. This may cause unnecessary VMA fragmentation
> and potentially worse performance on filesystems that do not actually
> support THPs and thus cannot benefit from the alignment.
>
>
> I'm not sure about the "VMA fragmentation" argument, really. We only consider
> stuff that is already multiples of PMD_SIZE.
>
> Filesystem support for THPs is also not really something you would handle, and it's
> a problem that solves itself over time as more filesystems keep adding support for
> large folios.
>
> So I think we should try limiting it to IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE),
> but not checking the runtime toggle.
That's a fair point about the runtime toggle. Limiting it to
IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) sounds reasonable.
Thanks,
Rui
© 2016 - 2026 Red Hat, Inc.