[PATCH v2 3/4] elf: Align large load segments to PMD huge page size for THP

[WANG Rui]

On Thu, Feb 26, 2026 at 9:23 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Adhemerval Zanella Netto:
>
> >> diff --git a/sysdeps/unix/sysv/linux/wordsize-64/dl-map-segment-align.c b/sysdeps/unix/sysv/linux/wordsize-64/dl-map-segment-align.c
> >> new file mode 100644
> >> index 0000000000..3c57d593bd
> >> --- /dev/null
> >> +++ b/sysdeps/unix/sysv/linux/wordsize-64/dl-map-segment-align.c
> >
> > Move this to sysdeps/unix/sysv/linux/dl-map-segment-align.c; I think this
> > should be a generic change and it should be applicable to 32-bit as
> > well (and I would prefer to avoid adding wordsize-64 definitions, it
> > complicated the syscalls defintions a lot).
>
> I think this should be LoongArch-specific for now because I don't think
> there is sufficient commonality among MMU implementations (and I'm not
> sure how unified the THP implementation in the Linux kernel is today).
> The alignment heuristic may only be applicable to LoongArch.

Thanks for raising this concern.

Originally the implementation did rely on deriving the PMD huge page
size from page table parameters, so I agree that in that form it would
have been questionable to make it generic.

However, in the current version the huge page pmd size is obtained
directly from the kernel at runtime. We no longer assume anything
about the MMU layout, page table structure, or arch-specific PMD
semantics. The alignment logic simply follows the huge page
granularity reported by the kernel.

As far as I understand, the THP collapse itself lives in the generic
mm subsystem in the Linux kernel. The arch-specific part mainly
determines what huge page sizes are supported, but whether a mapping
is eligible for collapse depends on alignment and contiguity, not on
arch-specific heuristics. Since we now use the kernel-reported huge
page size, the behavior should naturally adapt to each architecture.

Also, this change only adjusts the mmap address hint for sufficiently
large segments. It does not change load semantics or ABI-visible
behavior. If an architecture does not benefit from this alignment, it
can still override the hook.

Given that, it seems more like a Linux-level policy optimization
rather than a LoongArch-specific tuning. But I’m happy to adjust if
there are concrete cases where this assumption would not hold.

Thanks,
Rui

>
> But maybe the heuristic applies to all relevant AArch64 implementation
> as-is?  That would be surprising to me.
>
> Thanks,
> Florian
>