[RFC] Add GNU_PROPERTY_1_NEEDED_THP_ON_[READ_ONLY_SEGMENTS|MALLOC]

[Jan Beulich]

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.

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

Jan