[RFC] Add GNU_PROPERTY_1_NEEDED_THP_ON_[READ_ONLY_SEGMENTS|MALLOC]

[H.J. Lu]

On Thu, Apr 23, 2026 at 10:34 PM Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
>
> Hi HJ,
>
> > Transparent Huge Pages (THP) has been enabled in glibc to use THP on
> > THP eligible read-only segments and malloc to improve application
> > performance.  But there are some common issues & trade-offs of THP:
>
> All that is out of date. On modern Linux kernels repeated runs show
> deterministic gains. And not a single regression.

Are you suggesting these database applications are using THP now?

> > THP shouldn't be always enabled on THP eligible read-only segments nor
> > in malloc automatically regardless if THP usage will improve or hurt
> > application performance:
>
> I don't agree. THP exists to be used - as the name suggests, it is transparent,
> so if enabled in the OS, we should use it to get performance gains without
> forcing users to do extra work.
>
> Note other allocators are often used because unlike GLIBC malloc, they make
> use of THP by default.

They will run into the same issue as:

https://sourceware.org/bugzilla/show_bug.cgi?id=34081

> > To enable developers per-application control over THP usage under madvise
> > THP mode, add the following bits to GNU_PROPERTY_1_NEEDED:
>
> Users can already use tunables and/or prctl to control THP. I don't see why we
> need more choices - especially when it just adds startup overhead.
>
> Note opt-in is fundamentally the wrong approach given THP has been enabled
> in various distros for over a decade.
>
> > Linker will set these bits in application if these bits are set in any
> > relocatable inputs.
>
> That doesn't solve the issue as to how users will set it. If it means adding a
> special assembly file to every application that might benefit from THP then it
> burdens developers with unnecessary extra effort. People will just switch to an
> allocator that is fast out of the box...
>

We can add a linker option,  -z thp=[all|malloc|rosegment], to enable
these properties in applications.


-- 
H.J.