RSS regression: v3.1.5 → v3.3.0 shows +81% VmRSS on musl/Alpine (26 MB → 47 MB)

[justeff]

Summary
Upgrading from mimalloc v3.1.5 to v3.3.0 (or v3.3.1) causes an ~81% increase in resident set size for a long-running Rust async service on Alpine/musl, with no application code changes.

Environment
OS: Alpine 3.21 (musl libc), aarch64-unknown-linux-musl static build
Compiler: Rust 1.94.1 via cc crate (musl-gcc)
Build flags: LTO (fat), codegen-units = 1, panic = abort
Runtime: tokio (8 worker threads), long-running HTTP + MQTT service
Observed on: Linux/Kubernetes (Docker), macOS/Podman (Apple Virtualization, ARM64)

Measurements
Idle RSS after startup + health-check warmup, read from /proc//status (VmRSS):

mimalloc C version	Rust crate	VmRSS
v3.1.5	0.1.48 + features=["v3"]	26 MB
v3.3.0	0.1.49	45 MB
v3.3.1 (latest)	0.1.50	47 MB
v2.2.2 (default in 0.1.48)	0.1.48 (no v3 feature)	54 MB

All builds from the same application source, same compiler, same flags — only the mimalloc version differs.

Reproduction

1. Build the same Rust binary twice: once linking mimalloc v3.1.5, once linking v3.3.1
2. Run both on Alpine/musl (aarch64 or x86_64)
3. Compare VmRSS after a few seconds of idle + health-check traffic

Workaround
Pinned to mimalloc crate 0.1.48 with features = ["v3"] (→ C v3.1.5).

Possibly related
#1104 — arena lock contention / page-map overhead in dev3+
#1014 — memory regression reported by Bun
#1025 — excessive memory retention

[daanx]

Yikes. Hmm, I wonder if this is related to THP; can you try to run with MIMALLOC_ALLOW_THP=0 in the environment?

(otherwise, is there a somewhat easy way for me to reproduce this?)

[justeff]

Thanks for the quick response!

Confirmed, MIMALLOC_ALLOW_THP=0 fully resolves the RSS difference. We'll unpin from v3.1.5 and use this instead.

One follow-up question: what are the practical benefits of THP for mimalloc? Our service is a fairly typical async HTTP/MQTT server. Is there a performance trade-off we should be aware of when disabling THP?

[daanx]

pff, glad we identified the issue :-) .. but it does pose the question whether we should enable THP by default or not. The issue is probably occurring because in 3.3.0+ we try to avoid breaking up THP large pages by only purging full 2 MiB ranges. Of course, this can lead to increased fragmentation which is what you observed.

[dayvejones]

Thanks for the tip.

With MIMALLOC_ALLOW_THP=0, RAM consumption dropped by about 2 times (from 50 MB to 24 MB).

I use mimalloc in docker container with almalinux-micro for a web service on rust.

It seems that THP needs controlled tuning, depending on the type and intensity of the load.