The RSS That Would Not Fall

A long-running service allocates and frees millions of 200-byte request objects. After a traffic spike ends it frees everything and goes idle. top still shows RSS at 4.2 GiB and it stays there for hours with no new allocations. Valgrind reports no leaks and the heap profiler agrees that live bytes are near zero.

What is the best explanation?

RSS includes pages that have been written to swap, so the memory is already gone and only the accounting is stale.

free returns chunks to the allocator's free list, not to the kernel. The heap can only be shrunk by moving the break down, which requires the free space to sit at the very top and to exceed the trim threshold; a free chunk below any live chunk is unreachable to the kernel.

The kernel reclaims freed pages lazily and RSS will fall on its own within a few minutes under any memory pressure.

Valgrind is being fooled by the pooling layer, and the frees are not actually running.