malloc: Improve documentation of malloc tunables

Dev Jain dev.jain@arm.com
Wed Mar 11 06:32:36 GMT 2026



On 10/03/26 10:02 pm, Adhemerval Zanella Netto wrote:
> 
> 
> On 10/03/26 12:56, Wilco Dijkstra wrote:
>>
>> Update default for tcache_count tunable.  Remove existing documentation and
>> mention removal of fastbins in mxfast tunable.  Improve wording of hugetlb
>> tunable, including default for AArch64.
>>
>> OK for commit?
> 
> It does not address the value returned by --list-tunables, which can be
> misleading; nor the issues about memory consumption raised by Dimitri.

The memory consumption issue can be fixed perhaps by not aligning the main
arena heap extension (sbrk) to thp_pagesize. I don't think the secondary
heaps are any problem since, the section of the virtual mapping being
converted to PROT_READ | PROT_WRITE is exactly the size demanded by
the user - suppose out of a 2M section, only 1K section is read-write'd.
Linux will not install a 2M THP underlying this, because the protection
flags are different.

Second, since Dimitri said in the bug report that they are on a low
memory to cpu ratio system, the real question to ask is why is the
sysfs setting saying madvise/always instead of never.

> 
> I really think we should be more conservative and *not* make this default
> and only enable through the tunable.  With system-wide tunables we will
> have an option to enable this as side-wide if user do want it. 
> 
>>
>> ---
>>
>> diff --git a/manual/tunables.texi b/manual/tunables.texi
>> index 72769428e8cac27723fdec9ad83a92dc0b27415a..5850945a59e8494a2bb315da5a3e919112c5c562 100644
>> --- a/manual/tunables.texi
>> +++ b/manual/tunables.texi
>> @@ -231,37 +231,29 @@ per-thread cache.  The default (and maximum) value is 1032 bytes on
>>  @end deftp
>>  
>>  @deftp Tunable glibc.malloc.tcache_count
>> -The maximum number of chunks of each size to cache. The default is 7.
>> +The maximum number of chunks of each size to cache. The default is 16.
>>  The upper limit is 65535.  If set to zero, the per-thread cache is effectively
>>  disabled.
>>  
>>  The approximate maximum overhead of the per-thread cache is thus equal
>>  to the number of bins times the chunk count in each bin times the size
>> -of each chunk.  With defaults, the approximate maximum overhead of the
>> -per-thread cache is approximately 236 KB on 64-bit systems and 118 KB
>> -on 32-bit systems.
>> +of each chunk.
>>  @end deftp
>>  
>>  @deftp Tunable glibc.malloc.mxfast
>> -One of the optimizations @code{malloc} uses is to maintain a series of ``fast
>> -bins'' that hold chunks up to a specific size.  The default and
>> -maximum size which may be held this way is 80 bytes on 32-bit systems
>> -or 160 bytes on 64-bit systems.  Applications which value size over
>> -speed may choose to reduce the size of requests which are serviced
>> -from fast bins with this tunable.  Note that the value specified
>> -includes @code{malloc}'s internal overhead, which is normally the size of one
>> -pointer, so add 4 on 32-bit systems or 8 on 64-bit systems to the size
>> -passed to @code{malloc} for the largest bin size to enable.
>> +This tunable has no effect since the ``fastbins'' have been removed.
>>  @end deftp
>>  
>>  @deftp Tunable glibc.malloc.hugetlb
>>  This tunable controls the usage of Huge Pages on @code{malloc} calls.  The
>> -default value is @code{0}, which disables any additional support on
>> -@code{malloc}.
>> +default value is @code{0} on most targets.  Using @code{0} disables support
>> +that improves use of huge pages in @code{malloc}.  However huge pages may
>> +still be created depending on the OS settings.
>>  
>>  Setting its value to @code{1} enables the use of @code{madvise} with
>>  @code{MADV_HUGEPAGE} after memory allocation with @code{mmap}.  It is enabled
>>  only if the system supports Transparent Huge Page (currently only on Linux).
>> +This is the default used for AArch64.
>>  
>>  Setting its value to @code{2} enables the use of Huge Page directly with
>>  @code{mmap} with the use of @code{MAP_HUGETLB} flag.  The huge page size
>>
> 



More information about the Libc-alpha mailing list