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

[David Hildenbrand (Arm)]

On 3/12/26 17:12, hev wrote:
> Hi David,
> 
> On Thu, Mar 12, 2026 at 11:57 PM David Hildenbrand (Arm)
> <david@xxxxxxxxxx> 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@xxxxxxxxxx>
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