Soft freeze for the glibc-2.44 release

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Fri Jul 17 16:33:03 GMT 2026



On 17/07/26 13:04, Peter Bergner wrote:
> On 6/22/26 9:09 AM, Andreas K. Huettel wrote:
>> Please respond with your requests which features or fixes should still go in, 
>> and/or add them to the wiki page under blockers or desirables (unless they are
>> already listed there):
>> https://sourceware.org/glibc/wiki/Release/2.44#Planning
> 
> It would be nice to have some resolution on the large SPEC performance
> degradation [https://sourceware.org/PR34394] caused by:
> 
> 17a79a51208c5648fe70983085833bf15d83d0f1
> Author: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
> Date:   Thu Apr 2 13:56:10 2026 +0000
> 
>     malloc: Remove dynamic mmap/trim threshold [BZ #30769]
> 
>     v2: Update documentation
> 
>     Whenever a large mmap is released the mmap and trim thresholds are updated.
>     As a result these thresholds grow ever larger which means huge allocations
>     are always served by arenas rather than mmap.  The thresholds can end up as
>     large as an arena, which completely stops all trimming of the top block.
>     Remove the code completely - the default thresholds seem way too low for
>     modern 64-bit targets, but they can be increased seperately.
> 
>     Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
> 
> ...before the release goes out.  I'm not sure the best course of action though,
> whether we can get a fix for that, or whether we should revert the problematical
> commit for the release and try to fix it after?  Thoughts?
I think the safest approach is to revert it and work on having more
information for the next release.


More information about the Libc-alpha mailing list