(2012/04/15 1:28), Arnaldo Carvalho de Melo wrote: > Em Sat, Apr 14, 2012 at 10:55:19AM +0200, Ingo Molnar escreveu: >> >> * Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote: >> >>> Em Fri, Apr 13, 2012 at 11:30:52AM -0700, Linus Torvalds escreveu: >>>> On Fri, Apr 13, 2012 at 11:25 AM, Linus Torvalds >>>> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >>>>> >>>>> <kmem_cache_free>: >>>>> 1.91 : push %rbp >>>> >>>> Oh, btw, talking about kmem_cache_free: that one uses altinstructions, >>>> and so perf report shows the hottest instruction wrong (and I'm not >>>> talking about "ugly"): >>> >>> Well, if we use Masami's disassembler we would use the actual >>> code as it is being used and not the original DSO that was >>> later patched by altinstructions. >> >> Key would be to use the kernel's live RAM image of instructions. > > Yeah, that is what I meant by "if we use Masami's disassembler" :-) > >> I.e. we should provide a live /proc/vmlinux image in essence: a >> 'virtual' ELF binary image constructed out of the live kernel >> RAM image - with no extra RAM overhead. (Maybe with modules >> included in an intelligent way - although personally I don't use >> modules when I instrument the kernel) >> >> That plus the always-available /proc/kallsyms would offer rather >> powerful annotation already: without *any* debug info - out of >> box, on any Linux installation. (This was always the main >> advantage of /proc/profile and readprofile btw: it worked >> everywhere while most other profiling solutions needed a >> debuginfo, etc.) >> >> Doing /proc/vmlinux would be different from /dev/mem as it only >> shows the kernel RAM image, and only in a read-only fashion. If we can ignore permissions, we can check whether the instruction at the event address is modified or not in /dev/mem. And that is also useful for modules. That can be done in userspace with using setuid'd tool. >> Default permissions of /proc/vmlinux should probably track >> console permissions: it should be possible to allow people >> sitting in front of the computer to read /proc/vmlinux, while >> people logged in over the network wouldn't. >> >> Doing such a live kernel vmlinux would have other debugging and >> instrumentation advantages as well: various code patching >> effects could be checked and observed directly. > > I would say that even for userspace we would love to have such virtual > ELF files, as code patching is become more common... Right, if we hope to handle it correctly, we'll need to handle all self-modifying code in kernel/user space. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@xxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html