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