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:

> > Once the DSO is full -- equal to your previous anon-exec region being 
> > full, you simply mmap a new DSO.
> >
> > Wouldn't that work?
> 
> Okay and then whenever 'perf top' sees a non-mapped IP it reloads the 
> DSO (if it has changed)?
> 
> Yeah, I could see that working. It doesn't solve the problems Ingo 
> mentioned which are also important, though.

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)

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>