BufferNodeAllocatorTest.stress_free_list_allocator_vm is too expensive. This test accumulates ~1.5 GB of malloc footprint and raises the libc memory retention in my tests from 50m to 800m.

It is quite alone in its hunger. The rest of the tests together accumulate just ~50mb of libc retention.

The buffer does a stress test of the BufferNodeAllocator. Four "mutator threads" race four "gc threads". Mutator threads allocate buffers, GC threads release them. No processing is done on the buffers; this seems to be purely a test of the allocator and its freelist mechanism. The memory footprint of this test depends on the number of retained free buffers in the allocator. The allocator bulk-releases free buffers triggered by a free-count-threshold. On my box, the number of free items is 100k..200k.

To me, its not clear whether the fact that so many freelist items exist indicates a problem with the allocator itself. To me it looks like the free list should be drained if there are more than 10 items in this list.

But each buffer is capacity=1024, *sizeof(void*)+header, so 8KB+x, and with 100..200k of those alive it explains the NMT-reported malloc footprint of ~1.5GB. An easy fix is to reduce the size of this buffer; since they are not processed, their size should not matter. It may be good to keep them above a cache line size though to prevent false sharing during this test.