public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Tom Zanussi <zanussi@us.ibm.com>
To: Mathieu Desnoyers <compudj@krystal.dyndns.org>
Cc: ltt-dev@shafik.org, systemtap@sources.redhat.com
Subject: Re: Interoperability of LTTng and LTTV with SystemTAP
Date: Wed, 14 Dec 2005 18:25:00 -0000	[thread overview]
Message-ID: <17312.23427.225177.70858@tut.ibm.com> (raw)
In-Reply-To: <20051214022515.GA1488@Krystal>

Mathieu Desnoyers writes:
 > 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.
 > 

One area that seems tailor-made for this type of interaction would be
to use systemtap probes to detect 'interesting' conditions in the
trace data, at which point the buffered event stream to that point
could be dumped to disk for further analysis, leaving a detailed trail
of information as to what exactly led to a condition i.e. an
intelligent flight recorder.  'Interesting' conditions could comprise
a single event occurrence, but since probes can maintain state over
multiple events, more complex combinations of events ('compound'
events) could be detected as well.

Tom



  reply	other threads:[~2005-12-14 17:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-14  4:05 Mathieu Desnoyers
2005-12-14 18:25 ` Tom Zanussi [this message]
2005-12-14 18:47   ` Tom Zanussi
2005-12-16  0:55 ` Jose R. Santos
2005-12-16  1:09 ` Interoperability of LTTng and LTTV with SystemTAP (heavy usage) Mathieu Desnoyers
2005-12-17 14:27   ` LTTng very heavy system usage scenario Mathieu Desnoyers
2005-12-17 20:00     ` LTTng very heavy system usage scenario : probes Mathieu Desnoyers
2005-12-17 23:05   ` [ltt-dev] Re: Interoperability of LTTng and LTTV with SystemTAP (heavy usage) Mathieu Desnoyers
2005-12-19 22:12   ` Martin Hunt
2005-12-17 23:22 ` Interoperability of LTTng and LTTV with SystemTAP Marcelo Tosatti
2005-12-18 12:59   ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17312.23427.225177.70858@tut.ibm.com \
    --to=zanussi@us.ibm.com \
    --cc=compudj@krystal.dyndns.org \
    --cc=ltt-dev@shafik.org \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).