[RFC] Add GNU_PROPERTY_1_NEEDED_THP_ON_[READ_ONLY_SEGMENTS|MALLOC]

[H.J. Lu]

On Mon, Apr 20, 2026 at 4:03 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 20.04.2026 09:55, H.J. Lu wrote:
> > On Mon, Apr 20, 2026 at 1:56 PM Jan Beulich <jbeulich@suse.com> wrote:
> >> On 18.04.2026 01:24, H.J. Lu wrote:
> >>> On Fri, Apr 17, 2026 at 9:36 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>> On 17.04.2026 10:42, H.J. Lu wrote:
> >>>>> 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:
> >>>>>
> >>>>> 1. Latency Spikes: The background process (khugepaged) that consolidates
> >>>>> pages can cause temporary system freezes or high CPU usage.
> >>>>> 2. Memory Waste: Using a 2MB page for only 4KB of data can lead to
> >>>>> internal fragmentation and higher memory consumption.
> >>>>> 3. Database Incompatibility: Many databases (e.g., Oracle, MongoDB,
> >>>>> SAP ASE) recommend disabling THP because their non-contiguous access
> >>>>> patterns often trigger performance degradations.
> >>>>>
> >>>>> 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:
> >>>>>
> >>>>> 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:
> >>>>>
> >>>>> 1. GNU_PROPERTY_1_NEEDED_THP_ON_READ_ONLY_SEGMENTS
> >>>>>
> >>>>>  #define GNU_PROPERTY_1_NEEDED_THP_ON_READ_ONLY_SEGMENTS (1U << 1)
> >>>>>
> >>>>> to opt-in THP usage on read-only segments in an application.  When this
> >>>>> bit is set on executable, run-time loader should call madvise with
> >>>>> MADV_HUGEPAGE on all Transparent Huge Pages (THP) eligible read-only
> >>>>> segments in executable and its loaded shared libraries after they are
> >>>>> mapped into memory under madvise THP mode.
> >>>>
> >>>> Why would one (the main) executable control behavior for all involved
> >>>> shared libraries? Shouldn't each binary get its own say?
> >>>
> >>> Normally library developers don't know if THP usage in the library will
> >>> improve or hurt application performance.
> >>
> >> "Normally" as in what exactly? An entirely private shared library may be
> >> used by both an application wanting THP and one that doesn't. It
> >> containing, say, huge tables of data, it may very well benefit from THP
> >> itself, irrespective of the application's choice.
> >
> > Application developers should evaluate the overall impact of THP on the
> > application to decide if THP should be used for it.
>
> And that impact may also depend on the data the application acts upon. Plus,
> as said, the developers of a shared library may be in a better position to
> do such an evaluation for that library. And the "overall impact" may also
> be an entirely abstract thing: E.g. the set of shared libraries loaded may
> also vary across runs. I continue to think that this is too coarse grained.
> Even a per-binary bit may be too little, as different segments may want
> different settings.
>
> >>>>> 2. GNU_PROPERTY_1_NEEDED_THP_ON_MALLOC
> >>>>>
> >>>>>  #define GNU_PROPERTY_1_NEEDED_THP_ON_MALLOC (1U << 2)
> >>>>>
> >>>>> to opt-in THP usage in malloc in an application.  When this bit is set on
> >>>>> executable, malloc should call madvise with MADV_HUGEPAGE if the
> >>>>> allocated size is greater than or equal to THP page size after calling
> >>>>> mmap to allocate memory under madvise THP mode.
> >>>>
> >>>> Things are yet more fuzzy here, as you can't really control this by
> >>>> origin of a call to an allocation function.
> >>>
> >>> This will be checked by malloc in glibc to decide if madvise should be
> >>> called.
> >>
> >> "This" being what here? The new property? If so, then yes, sure, but how
> >> does that relate to the point I made?
> >
> > The malloc implementation in glibc checks the
> > GNU_PROPERTY_1_NEEDED_THP_ON_MALLOC bit
> > on the application.  The malloc implementation will use
> > madvise if the bit is set.
>
> IOW again "one bit controls everything".
>
> Jan

These bits provide a way to opt-in THP features automatically in
applications.   Do it at the shared library level have issues:

1. Malloc doesn't know which library it is called from.
2. Enable THP in the application because a library has the THP bits
removes the THP control in the application.

These bits address the opt-in issue at the application level.  They
aren't intended for something else.


-- 
H.J.