Re: malloc: Trim unused arenas on thread exit

[Florian Weimer <fweimer at redhat dot com>]

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