This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Implementing a generic binary trace interface.
Hi -
hunt wrote:
> If I understand it correctly, you propose getting a buffer, having
> numerous trace() calls, which the translator directly writes into the
> buffer, then a call to the runtime to send the accumulated trace data?
Yes, or rather Tom Zanussi did in
<http://sourceware.org/ml/systemtap/2006-q1/msg00257.html>.
My humble contribution is the notation - not struct field writes
but function calls.
> How would this interact with normal ASCII data (if you mix printf()
> with trace())?
I don't know, I'm only the notation guy. :-) I figure wherever the
proposed gbti function would plop its output is where this would go.
> Also how do you specify the format of the data stored?
The translator could actually emit some metadata (field names & types)
to allow decoding of the binary trace data, in the form of a perl
script, LTTV xml stuff, C struct declaration.
> [...]
> While I've got the numbers handy, I did some profiling and here are the
> results on my 2.6GHz desktop.
Thanks.
> printf() of 6 64-bit integers, converted to ASCII averaged 2.5 usecs
> [...] I expect a binary printf of 6 64-bit values to take between
> 0.2 and 0.4 usecs based on a quick prototype. ASCII printf
> performance could be improved too with a rewrite.
That's still orders of magnitude higher than a single binary
assignment. This may be one of those situations where the runtime's
assistance is neither helpful nor necessary.
- FCHE