[Bug libc/34394] Regression in cpu2006 403.gcc after removal of dynamic mmap/trim threshold

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=34394

--- Comment #2 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
I did a more comprehensible runs on x86_64 (AMD Ryzen 9 5900X, Ubuntu 24.04),
the metric is the median SPEC base ratio (higher = faster); delta % is relative
to Run1.

Configurations:

Run1 — base glibc build (reference, commit
bb91c88af78e9f862728623b60fb68d3610a4b79)
Run2 — second glibc build (regression 17a79a51208c5648fe70983085833bf15d83d0f1)
Run3 — Run2 with GLIBC_TUNABLES=glibc.malloc.mmap_threshold=4194304
Run4 — master with malloc defaults changed: DEFAULT_TRIM_THRESHOLD 8 MiB (was
128 KiB) and DEFAULT_MMAP_THRESHOLD 4 MiB (was 128 KiB)

As before, Run2 introduces significant regressions concentrated in a few
malloc-sensitive benchmarks: 403.gcc −19.4%, 465.tonto −19.4%, 481.wrf −13.2%.
Overall SPECint_base −2.0%, SPECfp_base −2.5%. Remaining benchmarks move within
±2% (run-to-run noise).

Run3 (mmap_threshold=4 MiB tunable) confirms the regression is malloc-threshold
related: 403.gcc fully recovers (+0.8% vs base), 465.tonto improves to −8.5%,
481.wrf to −9.0%. SPECint_base returns to +0.5%; SPECfp_base still −1.3%.

Run4 (raised trim + mmap defaults) is the best fix for the original
regressions: 403.gcc −0.8%, 465.tonto −4.4%, 481.wrf −6.4%. However it
introduces a new regression on 470.lbm −14.0%, leaving SPECfp_base at −2.1%
overall. The lbm regression appears to be a side effect of the raised trim
threshold and needs investigation before adopting these defaults.

So I am not sure if just incresing the default will fix this regression.

-- 
You are receiving this mail because:
You are on the CC list for the bug.