[Bug libc/34394] New: Regression in cpu2006 403.gcc after removal of dynamic mmap/trim threshold
anton at ozlabs dot org via Glibc-bugs <[email protected]> Mon, 13 Jul 2026 09:52:52 +0000
| Newsgroups | gmane.comp.lib.glibc.bugs |
|---|---|
| Message-ID | <[email protected]/bugzilla/> |
https://sourceware.org/bugzilla/show_bug.cgi?id=3D34394
Bug ID: 34394
Summary: Regression in cpu2006 403.gcc after removal of dynamic
mmap/trim threshold
Product: glibc
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: anton at ozlabs dot org
CC: drepper.fsp at gmail dot com
Target Milestone: ---
We noticed cpu2006 403.gcc performance dropped significantly on a RISC-V
Spacemit-K3 system after a glibc update. The regression varies, but the wor=
st
case is s04.i at 35% slower. It was isolated to the following patch:
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 upda=
ted.
As a result these thresholds grow ever larger which means huge allocati=
ons
are always served by arenas rather than mmap. The thresholds can end u=
p 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]>
Not surprisingly the regression disappears when the threshold is increased:
GLIBC_TUNABLES=3Dglibc.malloc.mmap_threshold=3D4194304
We should bump the threshold as suggested in the commit message.
--=20
You are receiving this mail because:
You are on the CC list for the bug.=