Fun with tracepoints [LWN.net]

Fun with tracepoints

Posted Aug 19, 2009 16:18 UTC (Wed) by fuhchee (guest, #40059)
In reply to: Fun with tracepoints by oak
Parent article: Fun with tracepoints

[1] Systemtap seems nice, but it doesn't have the post-processing / visualization for the whole system like LTT does. I see it more like a tool to do more specific analysis tools.

I see what you mean. systemtap people are working on some GUI data graphing tools, but are just starting. (I got the impression though that LTTV was being deprecated in favour of eclipse-based widgets, which systemtap and other tools could feed data into also.)

However, for this kind of stuff it's a bit too complicated (e.g. in embedded environments where you don't want to run stap / compile the scripts on the device itself etc)

We hope to ease that pain by more automated cross-compilation/execution.

to post comments

Fun with tracepoints

Posted Aug 20, 2009 19:29 UTC (Thu) by oak (guest, #2786) [Link] (4 responses)

> I got the impression though that LTTV was being deprecated in favour of
eclipse-based widgets

Do you have any pointers to more information about this?

Fun with tracepoints

Posted Aug 20, 2009 19:32 UTC (Thu) by fuhchee (guest, #40059) [Link] (3 responses)

I don't want to misrepresent LTTng, so please do take all this
with a grain of salt, but this is what I gathered from the presentations
given at http://ltt.polymtl.ca/tracingwiki/index.php/TracingMiniSu...

Fun with tracepoints

Posted Aug 20, 2009 19:34 UTC (Thu) by fuhchee (guest, #40059) [Link] (2 responses)

Grr, URL screwup, try this:
http://ltt.polymtl.ca/tracingwiki/index.php/TracingMiniSu...

Fun with tracepoints

Posted Aug 20, 2009 20:58 UTC (Thu) by oak (guest, #2786) [Link] (1 responses)

Thanks! According to this:
http://eclipse.org/linuxtools/projectPages/lttng/

"The first release, scheduled for September 2009 (code name: Vanilla),
will provide feature parity with the LTTng Viewer (LTTV) v0.12.12."

And this seemed to have a screenshot of the LTTng plugin:
http://ltt.polymtl.ca/tracingwiki/images/0/00/TMF_-_Traci...

This was pretty good overview of past & present tracing:
http://ltt.polymtl.ca/tracingwiki/images/5/57/Ts2009-hell...

Architecture bit here was annoying:
http://ltt.polymtl.ca/tracingwiki/images/4/46/Ts2009-Syst...

As it assumes that one has a working user-space in problematic cases one
wants to analyze. Kernel should be able to optionally get the data out
also through some high-speed HW interface without going through user-space
and filling of the flight record buffer would better not rely on
user-space.

Fun with tracepoints

Posted Aug 22, 2009 16:23 UTC (Sat) by compudj (subscriber, #43335) [Link]

About your comment on the architecture, I just want to clarify a few points. First, the architecture diagram you see at http://ltt.polymtl.ca/tracingwiki/images/4/46/Ts2009-Syst... focuses on tracing of userland. In this diagram, kernel tracing is contained within the "kernel trace facilities" box. For user-space tracing, where the goal is to get data out of the applications, it makes sense to consider than user-space is working. As you point out, this assumption makes less sense when we talk about tracing the kernel.

Second, more specifically about the LTTng kernel tracer, you are right in that the current mechanism used to extract data is a splice() system call controlled by a user-space daemon. However, alternate implementations of ltt-relay-alloc.c and ltt-relay-lockless.c could easily permit to use a high-speed debug interface. This has already been done with earlier LTTng versions for ARM.

The core of the LTTng kernel tracer therefore does not depend on userland. It's only the peripheral data extraction and trace control modules which depend on working userland. But they could be replaced easily by built-in kernel objects interacting directly with the LTTng kernel API. I made sure all operations we allow from interfaces presented to user-space are also doable from within the kernel.

Mathieu