Re: [PATCH][RFC] Allow explicit shrinking of arena heaps using anenvironment variable

[KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>]

(7/30/12 1:30 PM), Siddhesh Poyarekar wrote:
> On Mon, 30 Jul 2012 11:30:44 -0400, KOSAKI wrote:
>> ... but, I don't understand the benefit of this proposal. nowadays,
>> security paranoia always do zero clear before calling free for
>> sensitive data. Can anyone please tell me which programs get a benefit
>> from this change?
> 
> The original intent of the feature was to see utilization in arena maps
> similar to one would see in a heap; shrinking and growing of the 'heap'
> visible to the user via the /proc/maps of the process. That has turned
> into a discussion of whether there is any real performance difference
> between the mmap(MAP_FIXED) and the MADV_DONTNEED to warrant the
> conditional. I am supposed to write some tests to benchmark this, but I
> haven't gotten to doing it yet.

munmap also need tlb shoot down and mmap(MAP_FIXED) region overwritten
internally call munmap in kernel. so i don't think tlb shoot down makes
performance difference.

mmap(MAP_FIXED) and MADV_DONTNEED have different concurrency level.
mmap() take a write lock of mmap_sem. MADV_DONTNEED only takes read lock.
(note: it's no difference if program is single threaded. mamp_sem is 
per-process lock)

now i don't see any performance advantage in mmap. but i might be missing
something.

However, MADV_DONTNEED don't makes any /proc/maps change. so it can't be
used to see utilization in arena maps.

So, I wonder if libc malloc have some fine grained LIBC_PROBE() and it can
be analized from systemtap or something else. that's obviously low overhead
than pte purge everytime.