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.