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

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

--- Comment #2 from Adhemerval Zanella <adhemerval.zanella at linaro dot or=
g> ---
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 =3D faster); delta % is re=
lative
to Run1.

Configurations:

Run1 =E2=80=94 base glibc build (reference, commit
bb91c88af78e9f862728623b60fb68d3610a4b79)
Run2 =E2=80=94 second glibc build (regression 17a79a51208c5648fe70983085833=
bf15d83d0f1)
Run3 =E2=80=94 Run2 with GLIBC_TUNABLES=3Dglibc.malloc.mmap_threshold=3D419=
4304
Run4 =E2=80=94 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 =E2=88=9219.4%, 465.tonto =E2=88=9219.=
4%, 481.wrf =E2=88=9213.2%.
Overall SPECint_base =E2=88=922.0%, SPECfp_base =E2=88=922.5%. Remaining be=
nchmarks move within
=C2=B12% (run-to-run noise).

Run3 (mmap_threshold=3D4 MiB tunable) confirms the regression is malloc-thr=
eshold
related: 403.gcc fully recovers (+0.8% vs base), 465.tonto improves to =E2=
=88=928.5%,
481.wrf to =E2=88=929.0%. SPECint_base returns to +0.5%; SPECfp_base still =
=E2=88=921.3%.

Run4 (raised trim + mmap defaults) is the best fix for the original
regressions: 403.gcc =E2=88=920.8%, 465.tonto =E2=88=924.4%, 481.wrf =E2=88=
=926.4%. However it
introduces a new regression on 470.lbm =E2=88=9214.0%, leaving SPECfp_base =
at =E2=88=922.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.

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