[RFC] Add GNU_PROPERTY_1_NEEDED_THP_ON_[READ_ONLY_SEGMENTS|MALLOC]

[H.J. Lu]

On Fri, Apr 17, 2026 at 11:32 PM WANG Rui <wangrui@loongson.cn> wrote:
>
> On Fri, Apr 17, 2026 at 4:43 PM H.J. Lu <hjl.tools@gmail.com> 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.
> >
> > 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.
> >
> > Linker will set these bits in application if these bits are set in any
> > relocatable inputs.
>
> Linux also provides another per-process control for THP [1]. But
> relying on an ELF property, or on the application explicitly opting
> in, does not help existing binaries unless they can be rebuilt or
> modified.

Adding a new property bit never changes the existing binary.
It just proves a way to opt-in a feature since enabling THP blindly
for all applications doesn't improve performance everywhere.

> glibc tunables are more flexible here. The same program may prefer THP
> in performance-sensitive cases, but want it disabled under memory
> pressure.
>
> Also, with mTHP support, lack of benefit from PMD-sized THP for a
> workload does not imply that other THP sizes are also unhelpful. In
> that sense, a static opt-in flag seems too limiting?

This is a separate problem.   Do you have any performance data on it?

>
> [1] https://docs.kernel.org/admin-guide/mm/transhuge.html#process-thp-controls
>
> Thanks,
> Rui
>
> >
> >
> > --
> > H.J.
>


-- 
H.J.