free() does not physically trim/reclaim memory

Goffredo Baroncelli kreijack@inwind.it
Thu Sep 1 21:14:00 GMT 2016


On 2016-09-01 20:24, shuxin yang wrote:
> Hi, There:
> 
>     My environment is Linux with "Ubuntu GLIBC 2.21-0ubuntu4" (this is what ldd --version gives).
> 
>     In my application, I need to call mmap() a block right after BSS in order to prevent heap from growing.
> Then, the subsequent "malloc(not-very-big-size)" is to carve a block from a mmap()-ed block.
> It seems to me that the corresponding free() does not physically reclaim the memory unless I
> explicitly call malloc_trim().
> 
>     Could you please shed some light on this issue?
> 
>     I reproduce the problem with the following snippet, and observe RSS size using command
> "smem  -P "a\.out"

Disclaimer: I am not a libc expert; I have only played a bit with your code.

1) free(3) calls malloc_trim(3) if the block to free is greater than 128K. See mallopt(3), and the M_TRIM_THRESHOLD parameter. If you set M_TRIM_THRESHOLD to 126K or you allocate block greater 128k, you will observer the behavior that you expect.

2) this is a minor thing: it is not sufficient to allocate memory with malloc, but you have also to access it in order to make a real allocation. 
If you add a memset(p[i], 0, 127*1024); after the malloc(), you can see that the RSS go from about 17MB to about 500MB. In fact 4096*127*1024 = 508MB.


> 
>    Profuse thanks in advance!
> 
> Shuxin

BR
G.Baroncelli

[...]

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5



More information about the Libc-help mailing list