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

[hev <r@hev.cc>]

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