This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Interoperability of LTTng and LTTV with SystemTAP


Mathieu Desnoyers wrote:

Hi,

I just had a discussion with Frank Ch. Eigler from the SystemTAP team on the
topic "how can the tools cooperate well together".

SystemTAP is especially made for running user defined scripts at specific points
in the kernel. I has the ability to add/remove scripts and instrumentation
dynamically from a running kernel.

LTTng is a kernel tracer designed to have the minimum impact on the system while
having a design solid enough that it can trace NMI handlers (no locking). It
supports native C types and alignment. It can register new instrumentation sites
from dynamically loaded modules on-the-fly.

LTTV is a modular text/graphical trace analysis tool. You can think of it as
framework offered for plugins to interact together to show information. Simple
plugins can show generically some information (detailed event list, for
instance), while more sophisticated plugins can show a particular representation
of the system (each process state (user mode, system call, interrupted,
in trap, ...) evolving through time).

While the SystemTAP project focus on pre-processing of the information, LTT
focus on raw data copy (limiting the impact at probe site) at the cost of more
data to be transferred and analysed afterward.

I think that both approaches are complementary. I am trying to see where
integrated analysis of pre-processed and post-processed information could be
interesting, but I'm sure there are areas where it is.

If you have application ideas, feel free to express yourself.



We have a team that is working on implementing a kernel event trace tool using Systemtap. The project does not have a post-processor and I think it would be really cool to create a program that converts the Systemtap trace output into something the other visualizers can use. The first one that came to mind was LTTV. While the overhead right now is quite high compared to LTTing, the target of this trace utility is for situations were parching a kernel is not an option. We now have several trace hooks implemented and expect to release the code to the mailing list with in the next couple of days.


We plan on investing a significant portion of our time next year addressing some of the performance issues but performance will probably not be as fast as LTTing. Designing a common set of trace hooks for both the Systemtap and LTTing implementations will help people move between one and the other with out a significant learning curve. As long as the visualizer can handle both trace formats, I believe that both projects can complement each other.

-JRS


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]