Pekka Enberg <penberg@xxxxxxxxxx> writes: > On 7/4/13 7:54 AM, Eric W. Biederman wrote: >> How can adding glittler to /proc/<pid>/maps and /proc/<pid>/smaps >> justify putting a hand break on the linux kernel? > > It's not just glitter, it's potentially very useful for making > perf work nicely with JVM, for example, to know about JIT > codegen regions and GC regions. Ah yes. The old let's make it possible to understand the performance and behavior by making the bottleneck case even slower. At least for variants of GC that use occasionally make have use of mprotect that seems to be exactly what this patch proposes. > The implementation seems very heavy-weight though and I'm not > convinced a new syscall makes sense. Strongly agreed. Oleg's idea of a simple integer (that can be though of as a 4 or 8 byte string) seems much more practical. What puzzles me is what is the point? What is gained by putting this knowledge in the kernel that can not be determend from looking at how user space has allocated the memory? The entire concept feels like a layering violation. Instead of modifying the malloc in glibc or the jvm or whatever it is propsed to modify the kernel. Even after all of the discussion I am still seeing glitter and hand breaks. Eric -- 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>