Comment by masklinn

glibc does NOT return memory to the OS just fine.

In my experience it delays it way too much, causing memory overuse and OOMs.

I have a Python program that allocates 100 GB for some work, free()s it, and then calls a subprocess that takes 100 GB as well. Because the memory use is serial, it should fit in 128 GB just fine. But it gets OOM-killed, because glibc does not turn the free() into an munmap() before the subprocess is launched, so it needs 200 GB total, with 100 GB sitting around pointlessly unused in the Python process.

This means if you use glibc, you have no idea how much memory your system will use and whether they will OOM-crash, even if your applications are carefully designed to avoid it.

Similar experience: https://sourceware.org/bugzilla/show_bug.cgi?id=14827

Open since 13 years ago. This stuff doesn't seem to get fixed.

The fix in general is to use jemalloc with

    MALLOC_CONF="retain:false,muzzy_decay_ms:0,dirty_decay_ms:0"

which tells it to immediately munmap() at free().

So in jemalloc, the settings to control this behaviour seem to actually work, in contrast to glibc malloc.

(I'm happy to be proven wrong here, but so far no combination of settings seem to actually make glibc return memory as written in their docs.)

From this perspective, it is frightening to see the jemalloc repo being archived, because that was my way to make sure stuff doesn't OOM in production all the time.