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.


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


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