Re: Implementing a generic binary trace interface.

[Tom Zanussi <zanussi at us dot ibm dot com>]

Frank Ch. Eigler writes:
 > 
 > "Jose R. Santos" <jrs@us.ibm.com> writes:
 > 
 > > 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 [...]
 > 
 > Could you specify *why*?  This is important, because a naive "struct"
 > construct in systemtap (involving string copying, integer casting) is
 > likely to rob you of any extra performance you might imagine this
 > would give you.
 > 

Just being allowed to avoid the kernel printf() functions should be a
big win - Jose says that's the reason the omininous 'this will slow
down your system very much' message is in the README.

Avoiding the run-time overhead is one part, but also not having to log
10 times the amount of data to get the same information would be nice.

With structs, you also know the size of the data to be logged ahead of
time, so you don't have to first sprintf it to a buffer, then copy the
number of bytes returned by sprintf() to another buffer.

 > 
 > > [...]
 > > probe kernel.function("sys_open")
 > > {
 > >       trace_extra.hookid = HOOKID_OPEN;
 > >       trace_extra.flags = $flags;
 > > [...]
 > >       lket_tracer(trace_extra);
 > > }
 > > 
 > > function lket_trace(trace_extra:struct) {
 > > [...]
 > >           trace_format.cpu = ...
 > > [...]
 > >           trace(trace_format, trace_extra)
 > > }
 > 
 > How do you folks imagine this working?  Treat the field names as if
 > they were array indexes, and trace() just iterates over the array?  In
 > any particular order?
 > 
 > Maybe what you're looking for is programming convenience, such as
 > varargs, or generic functions, or local arrays?
 > 
 > 
 > > [...]
 > > 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.
 > 
 > You might find that those fixed typing/size constraints are exactly
 > what allows the Hitachi code to go fast.
 > 

How is

	ent->args[i] = (long)va_arg(args, int64_t);

(from the BTI code) better than

      data->argi = (long)argi;

?

Tom