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: Implementing a generic binary trace interface.


William Cohen wrote:

Jose R. Santos wrote:
Hi folks,

My team is currently implementing a trace tool using SystemTap that currently does logging by means of printf mechanism. We want to move to a binary trace format but there is no such mechanism on SystemTap for doing this. I've looked at what the folks at Hitachi have done with BTI, but this seems to force a specific trace format that is not suitable for what we need. Ideally, the trace format should be left to the tapset using the interface not the BTI. I propose to slightly alter the BTI from Hitachi to allow other trace implementations to use the trace format that's most convenient for the people implementing them.

To facilitate this, Tom Zanussi has been talking about implementing a basic form struct to the SystemTap language. The basic idea of how the tapset would use the new BTI and struct data types looks like:

probe kernel.function("sys_open")
{
     trace_extra.hookid = HOOKID_OPEN;
     trace_extra.flags = $flags;
     trace_extra.mode = $mode;
     trace_extra.name = $filename;
     trace_extra.fd = $fd;

     lket_tracer(trace_extra);
}


function lket_trace(trace_extra:struct) {


         trace_format.timestamp = ...
         trace_format.cpu = ...
         trace_format.....
         .....

         trace(trace_format, trace_extra)
}


Unlike the BTI current implementation, the format of the trace hook is defined by lket_trace and not by the generic interface. This design has the following benefits over the Hitachi interface.


1) It allows for anyone to implement their own trace hooks as they see fit. Making it a truly generic interface.

2) It does not limit the number or type of arguments that a trace hook can have. The current implementation limits you to 16 data points of size long.


Aside from the support to add struct to the SystemTap language, the rest of the changes to the BTI should be pretty straight forward and they would not significantly impact the current work that Hitachi has done with their implementation.


Thoughts?

-JRS

Are you proposing something like the trace buffers in perfmon2?


http://www.hpl.hp.com/techreports/2004/HPL-2004-200R1.html
http://sourceforge.net/projects/perfmon2

The perfmon2 allows multiple types of trace buffers, each has a unique idetifier. The perfmon2 trace buffers can be interpretted in what ever manner desired. OProfile has used a version of this mechanism in perfmon to collect data on ia64 machines. The code that writes to the buffer can be custom. There is a default trace buffer that writes a data to the buffer.

-Will

-Will




No. The first thing Im proposing is to alter Hitachi's Binary Trace Interface (BTI) into something more generic that myself and other can use on their projects. What BTI does is basically write data into the SystemTap buffers in raw binary form. This reduces the overhead of using printf and it provides a smaller trace file. Masami Hiramatsu submitted their BTI patches Dec/2005 which I liked, but would like to see some small changes in order to not tie it to a particular trace format.

The second thing I'm proposing is to add support for a struct type in the SystemTap language to simplify the writing on trace hooks. This idea originally came from Tom Zanussi and he sold me on it. Adding support for a struct type structure in the SystemTap language would be of great use to simplify the writing of the trace hooks that use the binary trace interface. I believe Tom had already an idea of how to implement this on to SystemTap.

-JRS


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