[RFC] Add GNU_PROPERTY_1_NEEDED_THP_ON_[READ_ONLY_SEGMENTS|MALLOC]

[Jan Beulich]

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?

> 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.

Jan