Messages in this thread | | | Date | Mon, 14 Jul 2008 12:26:31 -0400 | From | Masami Hiramatsu <> | Subject | Re: [PATCH] simple dprobe like markers for the kernel |
| |
Hi James,
James Bottomley wrote: > This is just an incremental update based on feedback. The most > significant was that making the marker a compiler barrier will free the > inserter from worrying about the mark sliding around changes to named > variables (and thus having to worry about this in placement) at > practically zero optimisation cost. I also updated the code to drop and > asm section instead of using the static variable scheme. I also added > documentation and made the module loader ignore them (since modules > don't go through the vmlinux.lds transformations).
I'm very interested in your approach.
IMHO, as Aoki investigated, the overhead of markers is not so big unless we put a lot of them into kernel. And from "active" overhead point of view, it takes less than tens of nano-seconds, while kprobes takes hundreds of nano-seconds. Kprobe also has a limitation of probable points, it can't probe "__kprobes" marked functions. So, original markers still has advantages.
However, your approach is also useful, especially for embedding thousands of markers in kernel or drivers.
So I think it's better to use both of them as the situation demands.
I just have one comment on its name. Since it doesn't trace anything, so I'd rather like notation() or note_mark() than trace_simple(). :-)
Thank you,
> > I also added a simple versioning scheme (basically tack the version on > to the end of the section name). It can be used simply and even > provides backwards compatibility (just emit the old and the new > sections). > > If everyone's happy with this, I'll follow it up with the systemtap > changes to make use of them ... they've been incredibly helpful > debugging some of the CDROM problems for me so far. > > James
-- Masami Hiramatsu
Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division
e-mail: mhiramat@redhat.com
| |