This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: free() does not physically trim/reclaim memory
- From: Goffredo Baroncelli <kreijack at inwind dot it>
- To: Shuxin Yang <shuxinyang dot oss at gmail dot com>
- Cc: libc-help at sourceware dot org, "Yichun Zhang (agentzh)" <agentzh at gmail dot com>
- Date: Fri, 2 Sep 2016 22:02:09 +0200
- Subject: Re: free() does not physically trim/reclaim memory
- Authentication-results: sourceware.org; auth=none
- References: <57C8724B.3020707@gmail.com> <2eda01d8-9c3d-914e-73ea-a593016c263d@inwind.it> <57C8AA4E.7050700@gmail.com>
- Reply-to: kreijack at inwind dot it
On 2016-09-02 00:23, Shuxin Yang wrote:
> Hi, Goffredo:
>
> Thank you very much for the speedy response. Please see the following interleaving comment.
>
> On 09/01/2016 02:14 PM, Goffredo Baroncelli wrote:
>> 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.
> It somehow does not work at my side: none of following approaches works:
> - invoke the example by : LLOC_TRIM_THRESHOLD_=$((126 * 1024)) ./a.out
> - call 'mallopt(M_TRIM_THRESHOLD, 126 * 1024)' right after main() is entered.
>
> Am I missing something here?
>
> If I set MALLOC_MMAP_THRESHOLD_ to 126k, then the memory can be reclaimed immediately.
> (As far as I can understand the code, it is because each malloc(127k) ends up mmap() a "chunk"
> flagged as "mapped chunk", when free() is called, "mapped chunk" can be easily deallocated)
Sorry, but this was a my error: I wrote TRIM_THRESHOLD, but in my test I used MMAP_THRESHOLD. Our results matches. Even if I don't understand the result now....
>
>>
>> 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.
>>
> Yes, you are absolutely right!
>
> Thanks
>
> Shuxin
>
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5