Re: [PATCH] simple dprobe like markers for the kernel

[Masami Hiramatsu <mhiramat@redhat.com>]

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