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

[Ingo Molnar <mingo@kernel.org>]

* Pekka Enberg <penberg@kernel.org> wrote:

> On Fri, Jul 12, 2013 at 12:26 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> > Well, the JIT profiling case is really special - there we are 
> > constructing code and a symbol table on the fly. Talking to perf via a 
> > temporary file sounds unavoidable (and thus proper), because symbol 
> > information on that level is not something the kernel knows (or should 
> > know) about.
> >
> > I was arguing primarily in the context of the original patch: naming 
> > allocator heaps. Today the kernel makes a few educated guesses about 
> > what each memory area is about, in /proc/*/maps:
> >
> >  34511ac000-34511b0000 r--p 001ac000 08:03 1706770                        /usr/lib64/libc-2.15.so
> >  34511b0000-34511b2000 rw-p 001b0000 08:03 1706770                        /usr/lib64/libc-2.15.so
> >  34511b2000-34511b7000 rw-p 00000000 00:00 0
> >  7f5bdff94000-7f5be63c1000 r--p 00000000 08:03 1710237                    /usr/lib/locale/locale-archive
> >  7f5be63c1000-7f5be63c4000 rw-p 00000000 00:00 0
> >  7f5be63d6000-7f5be63d7000 rw-p 00000000 00:00 0
> >  7fff7677f000-7fff767a0000 rw-p 00000000 00:00 0                          [stack]
> >  7fff767dd000-7fff767df000 r-xp 00000000 00:00 0                          [vdso]
> >  ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
> >
> > ... but on any larger app there's lots of anon mmap areas that are ... 
> > anonymous! ;-) User-space could help out a bit by naming them. It's 
> > not like there's many heaps, so the performance overhead aspect is 
> > minimal.
> >
> > In the JIT case we have something different, a 'file IO' abstraction 
> > really: the JIT is generating (writing) new code and associated symbol 
> > records. So using temporary files there is natural and proper and most 
> > of the disadvantages I list don't apply because the sheer volume of 
> > new code generated dillutes the overhead of open()/close(), plus we do 
> > need some space for those symbols so a JIT cannot really expect to be 
> > able to run in a pure readonly environment.
> >
> > In the allocator/heap case we have a _memory_ abstraction it's just 
> > that we also want to name the heap minimally.
> >
> > For any finer than vma granularity user-space attributes the kernel 
> > cannot help much, it does not know (and probably should not know) 
> > about all user-space data structures.
> >
> > Right now I don't see any good way to merge the two. (might be due to 
> > lack of imagination)
> 
> I have no trouble with the imagination part but you make a strong point 
> about the kernel not helping at finer granularity than vma anyway.
> 
> The current functionality is already quite helpful for VMs as well. We 
> could annotate the different GC and JIT regions and make perf more 
> human-friendly by default.

One thing where we could help JITs is to offer a direct channel to any 
perf profiling process: a prctl(SYS_TRACE) which would send a free-form 
string to any profiling task interested in it.

This would be a glorified anonymous write() in essence, without using a 
temporary file.

The advantage would be that the string could be captured as-is and copied 
to the ring-buffer of the profiling task - instead of having to recover it 
later on.

This is a model that I'd generally advocate: a single channel [per 
CPU-ified] for instrumentation/tracing.

Thanks,

	Ingo

--
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>