Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

Andrew Morton
2006-09-15T20:01:06Z

On Fri, 15 Sep 2006 14:16:18 -0400
Karim Yaghmour <karim@opersys.com> wrote:

> > Although IMO this is a bit lame - it is quite possible to go into
> > SexySystemTapGUI, click on a particular kernel file-n-line and have
> > systemtap userspace keep track of that place in the kernel source across
> > many kernel versions: all it needs to do is to remember the file+line and a
> > snippet of the surrounding text, for readjustment purposes.
>
> Sure, if you're a kernel developer, but as I've explained numberous
> times in this thread, there are far more many users of tracing than
> kernel developers.

Disagree. I was describing a means by which a set of systemtap trace
points could be described. A means which would allow those tracepoints to
be maintained without human intervention as the kernel source changes.
(ie: use a similar algorithm and representation as patch(1)).

Presumably those tracepoints would have been provided by a kernel developer
and delivered to non-developers, just like static tracepoints.

> > (*) I don't buy the performance arguments: kprobes are quick, and I'd
> > expect that the CPU consumption of the destination of the probe is
> > comparable to or higher than the cost of taking the initial trap.
>
> Please see Mathieu's earlier posting of numbers comparing kprobes to
> static points. Nevertheless, I do not believe that the use of kprobes
> should be pitted against static instrumentation, the two are
> orthogonal.

People have been speeding up kprobes in recent kernels, to avoid the int3
overhead. I don't recall seeing how effective that has been.