[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.=