* Pekka Enberg <penberg@xxxxxxxxxx> 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>