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.


hunt wrote:

> [...]
> > That's still orders of magnitude higher than a single binary
> > assignment.  
> 
> Yes. It appears to be the buffer reservation and manipulation that is
> expensive. [...]

Please explain why you think so ("the").  Others have observed that
kernel vscnprintf is a problem too.

In any case, I don't like the binary tracing idea only because it does
away with some of the buffering/copying of the formatted output.  It's
because it eliminates run-time conditionals (interpreting of
formatting directives) and unnecessary copying of the individual data
values (to a runtime formatting function).  It's the difference
between compilation and interpretation.

> > This may be one of those situations where the runtime's
> > assistance is neither helpful nor necessary.
> 
> It may also be that a few tweaks of the current code can speed up
> everything and satisfy the requirement for a generic binary interface.

A glance at the runtime/transport code suggests that while there are
opportunities for improvement (e.g. copying between various buffers in
io.c vs transport/*), these benefits would be shared by both printf
and the hypothetical binary trace widget.

> I prefer not to create some special case until we understand the
> whole problem.

What understanding do you think we lack?


- FChE


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