LTTng and SystemTAP (Everyone who is scared to read this huge thread, skip to here)

[Mathieu Desnoyers]

* Ingo Molnar (mingo@xxxxxxx) wrote:
> so regarding the big picture we are largely on the same page in essence 
> i think - sub-issues non-withstanding :-) As long as LTT comes with a 
> facility that allows the painless moving of a static LTT markup to a 
> SystemTap script, that would come quite a bit closer to being acceptable 
> for upstream acceptance in my opinion.
> 
> The curious bit is: why doesnt LTT integrate SystemTap yet? Is it the 
> performance aspect?

Yes, for our needs, the performance impact of SystemTAP is too high. We are
totally open to integrate data coming from SystemTAP to our traces. Correct me
if I am wrong, but I think their project does an extensive use of strings in the
buffers. This is one, non compact, sub-optimal type, but it can do the job for
low rate events. I also makes classification and identification of the
information rather less straightforward. Plus, running a string format code in a
critical code path does not give the kind of performance I am looking for.

> Some of the extensive hooking you do in LTT could be 
> aleviated to a great degree if you used dynamic probes. For example the 
> syscall entry hackery in LTT looks truly scary.

Yes, agreed. The last time I checked, I thought about moving this tracing code
to the syscall_trace_entry/exit (used for security hooks and ptrace if I
remember well). I just didn't have the time to do it yet.

> I cannot understand that 
> someone who does tracing doesnt see the fundamental strength of 
> SystemTap - i think that in part must have lead to my mistake of 
> assuming that you opposed SystemTap.
> 

Can you find a way to instrument it dynamically without the breakpoint cost ?
System calls are a highly critical path both in a system and for tracing.

Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/