RFC: malloc automatic THP opt-in breaks madvise contract for container hosts

[Sun, Yutong]

> One question is if malloc THP usage should be opt-in or opt-out.
> If THP usage in malloc improves performance for majority cases,
> it should be opt-out.

We'd vote opt-in. On container hosts most processes are small (shims,
agents, runtime components) and don't benefit from THP. We're seeing
this across managed services using our distro. It feels like the default 
should follow the kernel madvise mode semantics.

> No. Yours is the first one I heard. But I am not surprised, given
> its side effects.

I expect more reports as distros pick up 2.43.

--
Yutong



On 4/16/26, 10:56 PM, "H.J. Lu" <hjl.tools@gmail.com <mailto:hjl.tools@gmail.com>> wrote:


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.






On Fri, Apr 17, 2026 at 1:25 PM Sun, Yutong <yutongsu@amazon.com <mailto:yutongsu@amazon.com>> wrote:
>
>
>
> On 4/16/26, 10:23 PM, "Sun, Yutong" <yutongsu@amazon.com <mailto:yutongsu@amazon.com> <mailto:yutongsu@amazon.com <mailto:yutongsu@amazon.com>>> wrote:
>
>
> Thanks for the pointer. The per-binary opt-in idea is interesting.
>
>
> To clarify our case — the issue is specifically malloc's thp_init()
> auto-calling madvise(MADV_HUGEPAGE) when the kernel is in `madvise`
> mode. Your proposal covers PT_LOAD segments which seems broader.
> Would a binary without the property effectively get no THP at all
> under `madvise` mode?


My proposal is specific to THP usage on read-only segments. THP usage
in malloc isn't impacted. A different bit is needed for malloc. One question
is if malloc THP usage should be opt-in or opt-out. If THP usage in malloc
improves performance for majority cases, it should be opt-out.


>
> Also, are you hearing similar reports from other distros as 2.43 rolls out?


No. Yours is the first one I heard. But I am not surprised, given
its side effects.


>
> Again, as I mentioned we're carrying a revert patch [1] for now and happy to move to
> whatever upstream solution lands.
>




--
H.J.