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

[WANG Rui]

On Sun, Apr 12, 2026 at 7:49 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Sun, Apr 12, 2026 at 6:51 PM WANG Rui <wangrui@loongson.cn> wrote:
> >
> > On Sat, Apr 11, 2026 at 8:15 PM Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
> > >
> > > Hi HJ,
> > >
> > > > A couple issues:
> > > >
> > > > 1.  We shouldn't assume what are in /sys/kernel/mm/transparent_hugepage/enabled
> > > > nor /sys/kernel/mm/transparent_hugepage/hpage_pmd_size.   We can
> > > > add a system call or AT_XXX values to get them.
> > >
> > > Indeed, reading those files turned out to be a bad idea. Adding AT_XXX sounds like
> > > a good idea - it's cheap for the loader to process a few extra entries.
> > >
> > > However until we have a way to easily get the THP settings at startup, we need an
> > > alternative without reading those files. We also need to override the PMD size if
> > > it is too large - the current patch limits it to 32MB and for AArch64 I force the THP size
> > > to 2MB for all base page sizes.
> > >
> > > > 2.  We should support THP enabled with madvise.  If the current kernel doesn't
> > > > support it, it should be updated.
> > >
> > > In the future, sure, but it is not a requirement for Rui's patch series.
> >
> > I agree. This patch is intentionally conservative and only improves
> > segment alignment while passively working with THP in "always" mode.
> >
> > We can move forward incrementally and evaluate the behavior in
> > practice before considering a more proactive use of madvise.
>
> 1. Since the THP setting can be changed at run-time in the user space,
> it is wrong for glibc to assume that THP is enabled with always.

If we take into account that the THP setting can change at run time,
then strictly speaking we can't reliably depend on the THP mode at
load time anyway.

In practice, the check here is more of a pragmatic safeguard, mainly
to avoid unnecessarily reducing ASLR entropy in cases where THP is
clearly not in use.

> 2. There are potential performance issues with THP enabled with always.
>
> I propose the following:
>
> 1.  Always check the THP setting at load-time.
> 2.  Check the tunable once at load-time.
> 3.  If THP isn't disabled by the tunable,
>       3a.  Load shared libraries at THP compatible addresses.
>       3b.  If THP is enabled with madvise, issue madvise on all THP
>              compatible executable load segments, including main
>              executable and shared libraries.
> 4.  Select an application and build it as PDE with THP compatible executable
> load segments.  Use PDE, instead of PIE, ensures that executable load
> segments have addresses suitable for THP under the existing kernel.
> 5. Compare its performance under never THP kernel, always kernel and
> madvise THP kernel.
>
> I can provide such glibc changes on top of yours.
>
> madvise THP kernel should have similar iTLB performance as always THP
> kernel.
>
> If the results are positive, we can make kernel changes to provide faster
> THP setting access and load PIE at THP compatible addresses.

That sounds like a useful direction to explore, and I'd definitely be
interested in collaborating on that.

For now, I suggest landing the current patch based on the THP "always"
case first, since it is relatively conservative and has a well-defined
scope.

Follow-up patches could then extend the behavior to cover the madvise
case, based on the results of the experiments you described.

Does that sound like a reasonable way to proceed?

Thanks,
Rui