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

[Karim Yaghmour <karim@opersys.com>]

Ingo Molnar wrote:
> i have done a bit of kprobes and djprobes testing on a 2160 MHz Athlon64 
> CPU, UP. I have tested 2 types of almost-NOP tracepoints (on 2.6.17), 
> where the probe function only increases a counter:
> 
>  static int counter;
> 
>  static void probe_func(struct djprobe *djp, struct pt_regs *regs)
>  {
>          counter++;
>  }
> 
> and have measured the overhead of an unmodified, kprobes-probed and 
> djprobes-probed sys_getpid() system-call:
> 
>  sys_getpid() unmodified latency:    317 cycles   [ 0.146 usecs ]
>  sys_getpid() kprobes latency:       815 cycles   [ 0.377 usecs ]
>  sys_getpid() djprobes latency:      380 cycles   [ 0.176 usecs ]
> 
> i.e. the kprobes overhead is +498 cycles (+0.231 usecs), the djprobes 
> overhead is +63 cycles (+0.029 usecs).

But that's an entirely hypothetical benchmark. Mathieu was asked for
real-workload benchmarks and he gave you those. In turn, you set up
a simplistic test and then go on to conclude that the measurements
are far less than advertised. You ask that ltt replace its static
instrumentation by what kprobes provides and Mathieu demonstrated
that that's not realistic. If you want to change his mind, at least
reproduce the exact information ltt can provide and then we'll
talk.

> what do these numbers tell us? Firstly, on this CPU the kprobes overhead 
> is not 1000-2000 cycles but 500 cycles. Secondly, if that's not fast 
> enough, the "next-gen kprobes" code, djprobes have a really small 
> overhead of 63 cycles.

But djprobe isn't even here yet. If you insist on keeping ltt's
_current_ limitations as your single most powerful justification to
reject it, how you hold kprobes to a different standard with a
straight face? You're only perpetuating the fallacy found
throughout this thread that somehow the shortcomings of dynamic
editing are "easy" to fix while those of static instrumentation are
inherently unrecoverable. That's just plain not true, as I've
demonstrated now countless times in this thread.

And please Ingo, I'm still waiting for your feedback on the static
markup mechanism I proposed earlier. I believe it avoids every
single problem you alluded to with regards to the problems generated
by inline markup.

Thanks,

Karim
-- 
President  / Opersys Inc.
Embedded Linux Training and Expertise
www.opersys.com  /  1.866.677.4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/