Re: [PATCH 2.43] malloc: Show hugetlb tunable default in --list-tunables

Hi Wilco,

On Thu, 2026-08-13 at 13:52 +0000, Wilco Dijkstra wrote:
> The backport looks fine - I can do the commit if you don't have write access.

sure, thank you for the quick reaction! (no, I don't have write access)

> However I disagree with this part:
> 
> > ... but commit 2e8a940df14e
> > ("malloc: Avoid accessing /sys/kernel/mm files") has broken the tunable
> > again (glibc.malloc.hugetlb didn't affect mp_.thp_pagesize any longer).
> 
> Only setting mp_.thp_pagesize without madvise calls does not result in increased
> memory usage - it basically does the same as top_pad: it rounds up allocations
> to reduce the number of mmap/sbrk system calls. You need to access each page
> to get actual memory allocated to it.

I believe the pages are getting accessed, but the side effect comes on the systems
which always had

/sys/kernel/mm/transparent_hugepage/enabled: [always] madvise never

so madvise() syscall plays no role for them, but padding does.

> In the future we'll use MADV_DONTNEED and MADV_FREE more to release memory.
> This will likely cause confusion since the pages may not immediately be released by
> the kernel. And similar to above case, the mmap remains valid (and accessing the
> freed pages will allocate a new page).
> 
> So if you count the total mmap space rather than actual pages in use then memory
> use will appear much larger than it actually is.

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com