Re: [PATCH 2/2] mm: add a field to store names for private anonymous memory

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Jul 12, 2013 at 08:39:14AM +0300, Pekka Enberg wrote:
> On 07/12/2013 05:34 AM, Colin Cross wrote:
> >Userspace processes often have multiple allocators that each do
> >anonymous mmaps to get memory.  When examining memory usage of
> >individual processes or systems as a whole, it is useful to be
> >able to break down the various heaps that were allocated by
> >each layer and examine their size, RSS, and physical memory
> >usage.
> >
> >This patch adds a user pointer to the shared union in
> >vm_area_struct that points to a null terminated string inside
> >the user process containing a name for the vma.  vmas that
> >point to the same address will be merged, but vmas that
> >point to equivalent strings at different addresses will
> >not be merged.
> >
> >Userspace can set the name for a region of memory by calling
> >prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, start, len, (unsigned long)name);
> >Setting the name to NULL clears it.
> >
> >The names of named anonymous vmas are shown in /proc/pid/maps
> >as [anon:<name>] and in /proc/pid/smaps in a new "Name" field
> >that is only present for named vmas.  If the userspace pointer
> >is no longer valid all or part of the name will be replaced
> >with "<fault>".
> >
> >The idea to store a userspace pointer to reduce the complexity
> >within mm (at the expense of the complexity of reading
> >/proc/pid/mem) came from Dave Hansen.  This results in no
> >runtime overhead in the mm subsystem other than comparing
> >the anon_name pointers when considering vma merging.  The pointer
> >is stored in a union with fieds that are only used on file-backed
> >mappings, so it does not increase memory usage.
> >
> >Signed-off-by: Colin Cross <ccross@android.com>
> 
> Ingo, PeterZ, is this something worthwhile for replacing our
> current JIT symbol hack with perf?

I really don't see the point of this stuff; in fact I intensely dislike it as I
don't think this is something the kernel needs to do at all.

Why can't these allocators Collin talks about use file maps and/or write their
own meta-data to file? He is after all only interested in Android and they have
complete control over the entire userspace stack.

I also don't see it helping with the JIT stuff; you still need to write out a
file with symbol information, we still need to find the file. A less hacky
solution for the entire JIT thing is you writing a proper ELF-DSO and
mmap()'ing that :-)

Storing a JIT specific userspace pointer in the VMA doesn't help with any of
that.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>