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.

[daanx]

I just pushed a potential "fix" by keeping the default allow_thp=1 but no longer increasing the minimal purge size to 2 MiB -- this means the THP pages can get broken up but also probably fixes the increased RSS we see. Can anyone see if the latest dev3 now fixes this for you? (without using any environment variable). Using MIMALLOC_ALLOW_THP=2 gives the previous behaviour of automatically setting the minimal purge size to 2 MiB so that should be as before. Let me know how it goes.

[justeff]

From my side, no fix needed MIMALLOC_ALLOW_THP=0 works fine for me. I was just puzzled by the increased RSS and now know how to control it. I wouldn't want to be the reason something gets changed or broken elsewhere.

[dayvejones]

Hi! What if you try to leave MIMALLOC_ALLOW_THP=1, but reduce the MIMALLOC_MINIMAL_PURGE_SIZE value?

[daanx]

Hi! What if you try to leave MIMALLOC_ALLOW_THP=1, but reduce the MIMALLOC_MINIMAL_PURGE_SIZE value?

Yes, this is what I pushed to the latest dev3 as I would like the default to be "allow thp" (as that respects the user system policy). So MIMALLOC_ALLOW_THP can be:

• 0 : no THP -- mimalloc will turn off THP for its process
• 1 : allow THP -- mimalloc will use madvise to nudge the OS to using THP for large allocations (like the arena's)
• 2 : allow THP and increase the minimal purge size to 2 MiB -- as 1 but this avoids potentially breaking up large THP pages when purging memory. However, this may increase rss by quite a bit (for some workloads) as shown in this thread.

@justeff, @dayvejones: It would be great to test if this actually fixes the issue. There is two ways to test this:

• use the (older) mimalloc you have (v3.3.0 or v3.3.1) and run with MIMALLOC_MINIMAL_PURGE_SIZE=4KiB and see if that has the same results as MIMALLOC_ALLOW_THP=0,
• or, download the latest mimalloc and run without anything to see if it also improves it. (and with MIMALLOC_ALLOW_THP=2 it should show the RSS increase again).

Thanks

[dayvejones]

MIMALLOC_MINIMAL_PURGE_SIZE=4KiB works great for me

[justeff]

Unfortunately, with MIMALLOC_MINIMAL_PURGE_SIZE=4KiB and w/o MIMALLOC_ALLOW_THP=0 I see an increased RSS usage again (48MB, mimalloc v3.3.1).