[PATCH] malloc: remember that thp_mode got probed

[Aurelien Jarno]

Hi Wilco,

On 2026-02-26 15:38, Wilco Dijkstra wrote:
> Hi Aurelien,
> 
> > On aarch64, following the new 2MB THP default introduced in 321e1fc73f53
> > and when /sys/kernel is not accessible (as in some containers [1]),
> > /sys/kernel/mm/transparent_hugepage/enabled is probed on every malloc()
> > call.
> 
> That's strange, does that mean containers don't support THP at all, ever?

No, depending on the container /sys/kernel could be hidden or not. For 
example it's available by default with docker or podman. But that just 
hides the information from libc, THP is still available at the mmap 
level.

In the long term it would be nice to have a better interface with the 
kernel (but that can take time!), as parsing a file is less than ideal.  
It means that seccomp filters [1] or apparmor profiles need to be update 
to allow access to that file in /sys.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1128916

> > This causes some performance regression, and also sets errno to ENOENT
> > on each malloc call. Some programs are not prepared for that (even
> > though they arguably should be), causing some regressions [2].
> 
> Interestingly that shows you get the exact same failures on any target if you
> set glibc.malloc.hugetlb=2. So perhaps we should try to avoid setting errno in
> malloc or just force errno=0 when we exit a path that may have used a system
> call? Mmap, sbrk and madvise can also set errno, including in cases where we
> retry and return a valid block.

Yes, it's not fully specific to aarch64, just that aarch64 has a 
different default.

> > Fix that by introducing a new THP state, malloc_thp_mode_unknown, which
> > is distinct from malloc_thp_mode_not_supported. This makes possible to
> > record that the THP mode has been probed and found as not supported,
> > avoiding repeatedly poking the file. In turns this "fixes" half of the
> > regressions found so far.
> 
> The patch is OK since it avoids repeated initialization, but we do need to decide
> how to handle errno in malloc (as this will still set errno on the first call to malloc
> if the THP check fails).

Yes, I agree, the patch only fully fixes the repeated initialization, 
and only improves the situation with errno. OTOH it seems that 
identified issues are getting fixed (for instance dovecot got fixed 
upstream), so I am not sure what to do.

> Reviewed-by: Wilco Dijkstra  <Wilco.Dijkstra@arm.com>

Thanks!

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net