Re: Soft freeze for the glibc-2.44 release

Adhemerval Zanella Netto <[email protected]>
Newsgroups gmane.comp.lib.glibc.alpha
Organization Linaro
Message-ID <[email protected]>

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 <[email protected]>
> 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  <[email protected]>
> 
> ...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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.