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

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

On Fri, 20 Jul 2012 14:45:36 -0400, Carlos wrote:
> On 7/20/2012 6:55 AM, Siddhesh Poyarekar wrote:
> > kernel that we don't want to use that part. For setuid programs, we
> > go a step further and ensure that the consolidated region to be
> > freed has no permissions, by calling mmap() on it with MAP_FIXED
> > and PROT_NONE.
> 
> Why do we do this for setuid programs? It isn't immediately obvious
> to me why it should matter.

There are two things that the mmap does and I suspect that it's the
second one that matters more:

1. Makes the freed mapping PROT_NONE, thus preventing access to that
   region
2. Discard the contents in that region, so that it cannot be read even
   by manually reverting the protection. Of course, there's no
   preloading available to inject such code, but even if there was a
   way to inject code, at least that memory would no longer be readable.

> > 2. One may want to look at memory maps in /proc/PID/maps and get an
> >    estimate of how much of it is in use, similar to the main process
> >    heap. The main process heap *actually* shrinks and hence it is
> > easy to see how much of it is in use, but for the arenas, there is
> >    currently no way to guess this. Until now. The way to identify
> > the vmas that are acting as arenas is to collate /proc/PID/maps
> > data with the strace of the program.
> 
> It is my opinion that if we want to know about arenas then we should
> write an API to expose their state to an in-process agent. Groking the
> maps is bad design for exposing such information.

Agreed that grokking maps is not reliable in a general case. An API may
expose such information within a program, but not to, say, a separate
monitoring program that would like to catch runaway processes earlier
than an OOM kill would. For such a scenario, heuristics using the maps
seem like the last resort, especially when the program design is known.

I can also use malloc_stats to dump arena information and parse it
somehow, but that would still require me to preload a library that runs
this function periodically either via an alarm or in a separate thread.
That or modify the source code.

In any case, I'd like to know if the change makes sense even without
this side-effect.

> > The default behaviour remains as before -- this new behaviour is
> > only seen when MALLOC_ARENA_SHRINK is exported and set to a
> > positive value.
> 
> Why don't we enable this unconditionally?
> 
> What would be the problem in doing that?

mmap is more expensive than madvise, with the zeroing of pages and all
that, so it might not be the best option to enable unconditionally. I
wonder what the performance improvement will be with doing a
memset(..., 0, ...) on the tail of the arena and then calling mprotect
instead of the mmap.

Regards,
Siddhesh