malloc: Trim unused arenas on thread exit
Florian Weimer
fweimer@redhat.com
Fri Nov 10 13:13:00 GMT 2017
On 11/10/2017 11:52 AM, Siddhesh Poyarekar wrote:
> On Thursday 09 November 2017 04:25 PM, Florian Weimer wrote:
>> I tried the attached patch to trim unused arenas on thread exit. The
>> trimming actually happens (the heap consolidation is visible in the
>> malloc_info output from tst-malloc_info), but the arena heaps aren't
>> deallocated.
>>
>> I think trimming unused arenas as much as possible is a good heuristics
>> to minimize RSS, so getting this to work might be worthwhile.
>
> I wonder if the overhead of unmapping the arena heaps is worthwhile.
> For cases where it matters (overcommit is a ratio or is disabled or for
> __libc_enable_secure), trimming of the heaps should reduce the commit
> charge already since we do remap the pages as PROT_NONE.
I would have expected that the test makes the second sub-heap completely
unused, so that the existing logic would unmap it. But that does not
seem to happen.
> The patch seems OK, I'm just wondering if the additional work is worth
> the effort because it will also hurt applications that spawn threads
> frequently and have similar resource usage; they'll miss out on the
> caching effect.
We could do this not for the current arena, but he arena at the op of
the free list. Then we'd return some caching, and you'd get a ping-pong
effect only if you stop and start more than one thread.
The consolidation we should still perform on the current arena, maybe
even if it is not unused. I assume that before the thread exits, it
deallocates some resources, and we should make sure that malloc sees
them once the arena is reused, even from a thread which has a vastly
different allocation pattern.
Thanks,
Florian
More information about the Libc-alpha
mailing list