[RFC] Add GNU_PROPERTY_1_NEEDED_THP_ON_[READ_ONLY_SEGMENTS|MALLOC]

[Wilco Dijkstra]

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.

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

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

Cheers,
Wilco