[PATCH] malloc: remember that thp_mode got probed

[Adhemerval Zanella Netto]

On 26/02/26 12: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?

I saw a similar failure with a custom built kernel where I forgot to enable
THP support and I was about to investigate this very issue after seeing
multiple openat fails.

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

We already do this for free [1], albeit for most free usage users do expect
this [2].

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=17924
[2] https://austingroupbugs.net/view.php?id=385

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

I think it QoI to keep errno untouched for malloc, the main work would be
to map where it is possible to just save/restore the errno in such cases.

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