Re: [PATCH v4 1/2] huge_mm: add stubs for THP-disabled configs

Lance Yang
2026-03-13T09:48:23Z

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.