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

WANG Rui wangrui@loongson.cn
Wed Feb 25 16:21:56 GMT 2026


On Wed, Feb 25, 2026 at 2:34 AM Xi Ruoyao <xry111@xry111.site> wrote:
>
> On Wed, 2026-02-25 at 00:05 +0800, WANG Rui wrote:
> > Mapping segments that are at least the size of a PMD huge page to
> > huge-page-aligned addresses helps make them eligible for Transparent
> > Huge Pages (THP).
> >
> > This patch updates the segment mapping logic in the generic ELF loader
> > to dynamically calculate the PMD huge page size based on the runtime
> > normal page size. On 64-bit systems, the number of page table entries
> > is (page_size / sizeof(void *)). Multiplying this by the page size
> > yields the PMD huge page size (e.g., a 4K normal page yields a 2M huge
> > page, and a 16K normal page yields a 32M huge page).
> >
> > For load segments where both the virtual address and file offset are
> > already aligned to this huge page size (e.g., zero), and the segment
> > size is large enough, we explicitly bump its alignment to the huge
> > page size. This optimization significantly reduces TLB pressure and
> > improves performance for large objects.
> >
> > To prevent excessive address space padding and memory waste on
> > architectures with very large normal pages (e.g., 64K pages yielding
> > 512M huge pages), the optimization is capped and only applies if the
> > calculated huge page size is 32M or less.
> >
> > * elf/dl-load.c (_dl_map_object_from_fd): Bump p_align_max to the
> > calculated PMD huge page size (capped at 32M) for large load segments
> > on 64-bit systems.
> >
> > Signed-off-by: WANG Rui <wangrui@loongson.cn>
> > ---
> >  elf/dl-load.c | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/elf/dl-load.c b/elf/dl-load.c
> > index 7355eef8e7..a8db4f3abc 100644
> > --- a/elf/dl-load.c
> > +++ b/elf/dl-load.c
> > @@ -1171,6 +1171,23 @@ _dl_map_object_from_fd (const char *name, const char *origname, int fd,
> >
> >         /* Optimize a common case.  */
> >         c->prot = pf_to_prot (ph->p_flags);
> > +
> > +#ifdef __LP64__
> > +       /* Dynamically calculate the PMD huge page size based on the normal
> > +          page size (e.g., 2M for 4K pages, 32M for 16K pages). Aligning
> > +          load segments that are large enough to the PMD size helps improve
> > +          THP eligibility and reduces TLB pressure.
> > +          We cap the huge page size at 32M to avoid over-aligning on systems
> > +          with very large normal pages (like 64K pages with 512M huge pages). */
> > +       size_t page_size = GLRO(dl_pagesize);
> > +       size_t huge_page_size = page_size * (page_size / sizeof (void *));
>
> Is this calculation of huge page size always correct?
> sysdeps/unix/sysv/linux/malloc-hugepages.c parses /proc/meminfo instead.
> But I don't know if we can open and parse files in such an early stage
> of dynamic linking.  Anyway at the very least the this is Linux-
> specific, so IMO the logic modifying p_align_max should be factored out
> to sysdeps/unix/sysv/linux/wordsize-64/.
>
> Would this affect ASLR and require LoongArch distros to raise
> CONFIG_ARCH_MMAP_RND_BITS to compensate?

On ASLR: yes, increasing p_align_max does reduce the number of
possible base addresses for the affected segments. However, this only
applies to large load segments that are already naturally aligned and
is capped at 32 MB. In practice this mainly affects very large
binaries, and the entropy reduction is comparable to what already
happens with THP-backed mappings. Distributions could choose to tune
ASLR independently if they consider it necessary.

Thanks,
Rui

>
> Technically we shouldn't be doing this on some circumstances, like if
> the kernel lacks THP support, or it is configured without
> CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS.  But maybe checking all of the
> conditions would be too hard.
>
> --
> Xi Ruoyao <xry111@xry111.site>



More information about the Libc-alpha mailing list