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

[Pekka Enberg <penberg@kernel.org>]

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.

                                Pekka

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