From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8493 invoked by alias); 15 Dec 2005 16:38:24 -0000 Received: (qmail 8391 invoked by uid 22791); 15 Dec 2005 16:38:21 -0000 X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_50,DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e33.co.us.ibm.com (HELO e33.co.us.ibm.com) (32.97.110.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 15 Dec 2005 16:37:58 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBFGbs7a031723 for ; Thu, 15 Dec 2005 11:37:54 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBFGb1Xg120002 for ; Thu, 15 Dec 2005 09:37:01 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jBFGbrGU006019 for ; Thu, 15 Dec 2005 09:37:53 -0700 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jBFGbq7I006000; Thu, 15 Dec 2005 09:37:53 -0700 Received: from [9.53.95.44] (jsantos@rx8.austin.ibm.com [9.53.95.44]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id jBFGbp58037288; Thu, 15 Dec 2005 10:37:51 -0600 Message-ID: <43A19BE9.5020903@us.ibm.com> Date: Fri, 16 Dec 2005 00:55:00 -0000 From: "Jose R. Santos" Reply-To: jrs@us.ibm.com Organization: IBM User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mathieu Desnoyers CC: ltt-dev@shafik.org, systemtap@sources.redhat.com Subject: Re: Interoperability of LTTng and LTTV with SystemTAP References: <20051214022515.GA1488@Krystal> In-Reply-To: <20051214022515.GA1488@Krystal> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2005-q4/txt/msg00450.txt.bz2 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