[RFC PATCH v2 0/1] malloc: madvise interior free chunks above a threshold

[Xavier Roche]

v2: rebased on master, hot-path hint added, comments tightened.

Changes since v1
----------------
- Rebased on current master (v1 was sent on 2026-04-21 and the
  TryBot-32bit check on patchwork now reports a stale-base apply
  failure, hence this refresh).
- __glibc_unlikely () on the trim-gate condition in
  _int_free_maybe_trim, per Rocket Ma's suggestion in BZ #33886
  comment 27.  The new madvise/trim path is cold; the hint keeps
  it out of the hot inline.
- Minor comment cleanup in malloc/malloc.c and the test, no
  behaviour change.

Substantive design unchanged.  The trade-offs flagged in the
v1 cover (default-on vs tunable; MADV_FREE/MADV_DONTNEED split
at 128 KB) are still open if you want to push back on either.

v1 thread:
https://inbox.sourceware.org/libc-alpha/cover.1776760573.git.xavier.roche@algolia.com/

BZ #33886 picked up some discussion in the meantime
(comments 22-27): one reviewer asked for mtrace + strace +
malloc_info captures to verify the patch is not changing the
allocation pattern or allocator state.  Captures attached to
the BZ thread, also runnable from the public reproducer:
https://github.com/xroche/glibc-malloc-hoarding-reproducer

Same headline numbers as v1
---------------------------
Reproducer: 16 threads, 256 MB live, 10 GB short-lived churn.

                          baseline    patched
  RSS after free           1247 MB    296 MB
  malloc_trim recovery      962 MB     14 MB   (free did the work)
  Runtime                  0.34 s     0.50 s   (tight malloc loop)

Testing
-------
- malloc test suite: 369 PASS, 0 FAIL on x86_64-linux-gnu.
- Full make check: no new regressions vs baseline.
- Cross-built via build-many-glibcs.py for aarch64-linux-gnu,
  arm-linux-gnueabihf, powerpc64le-linux-gnu, s390x-linux-gnu:
  all four pass check-compilers, build, and compile-only check
  with no new warnings on malloc.c.  i686 covered by patchwork.

Open questions (unchanged from v1)
----------------------------------
1. MADV_FREE vs MADV_DONTNEED split at 128 KB: keep the
   two-tier design, or always use MADV_DONTNEED (matches
   mtrim)?
2. Default-on vs tunable: the patch is default-on because
   this is a regression fix since 2.26.  A tunable
   kill-switch (default on) is a small follow-up if preferred.
3. Threshold values are picked as multiples of
   ATTEMPT_TRIMMING_THRESHOLD; open to tuning.

Acknowledgments
---------------
Wilco for the v1 review on BZ #33886 (concerns from comment 10
that shaped the accumulator design).  Rocket Ma for the
__glibc_unlikely hint and the mtrace/strace/malloc_info round
on the BZ.

Related prior art: Mel Gorman's 2015 RFC
(https://sourceware.org/legacy-ml/libc-alpha/2015-02/msg00193.html)
explored a related madvise refault-avoidance question; this
patch is narrower in scope.

AI disclosure
-------------
AI assistance (Claude) was used during analysis and drafting:
reading the ptmalloc2 source, reviewing the regression bisect,
exploring design alternatives, and iterating on the patch text.
The design decisions, the benchmark runs, and the final code
were reviewed and validated by the author, who takes
responsibility for correctness.

Xavier Roche (1):
  malloc: madvise interior free chunks above a threshold

 malloc/Makefile                |   1 +
 malloc/malloc.c                |  73 ++++++++++++++++---
 malloc/tst-madvise-threshold.c | 126 +++++++++++++++++++++++++++++++++
 3 files changed, 190 insertions(+), 10 deletions(-)
 create mode 100644 malloc/tst-madvise-threshold.c


base-commit: 1cc165baed20b6589ef2f2c8c0e0415139bbb151
-- 
2.43.0