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

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

(7/30/12 11:30 AM), KOSAKI Motohiro wrote:
>>> I don't see the difference in MADV_FREE and mmap+MAP_FIZED+PROT_NONE
>>> over top of the original map. If the latter is not fast enough it
>>> should just be optimized for this special case since portable software
>>> will already be using it for this purpose.
>>
>> They differ in the semantics they guarantee, though not in the apsect
>> that malloc cares about (when not in the __libc_enable_secure case).
>> With MADV_FREE, the kernel is not obliged to do anything at all, it can
>> just do nothing at all or it can just mark internal data structures, or
>> it can actually reclaim the pages right away--whatever it thinks is
>> optimal.  With mmap, the kernel is required to immediately flush the
>> pages so that any access is guaranteed to fault as soon as mmap returns.
>> That could be much more expensive.
> 
> If I understand correctly, security paranoia want to discard pte entry
> immediately likes MADV_DONTNEED otherwise it do nothing if system have
> much much memory.
> 
> Example, if the process crash after MADV_FREE, security sensitive data
> may store into core file.
> 
> ... 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?

sorry. you talked about no __libc_enable_secure case and I missed it. I
agree lazy discarding likes above MADV_FREE may help performance improvement.

Kernel folks sometimes received current MADV_DONTNEED usage in libc malloc makes
tons cow 4k memset(0) and it screw up cpu cache effectivity. but we couldn't help
them because we are not libc expert. Do anyone received the same claim on it? and
do anyone have more deep performance analysis?