Output Redesign in SystemTap Runtime

[Frank Ch. Eigler]

Hi -

> > Does this make my concern more clear?
> 
> Yes.  I did combine two different things under my "output redesign"
> document.  However they are (almost entirely) orthogonal issues. 

Indeed.

> [For] reconstructing a timeline from the per-cpu data files [...]
> it is necessary we have timestamps embedded in the streams.  It just
> makes sense to have them use the same xml syntax that higher-level
> objects will be using.

Actually, it really doesn't.  If the transport layer wants to pass
nested data safely, then it will have to encode xmlish characters like
"&", "<", etc., or as in XML PCDATA.  Given that the nesting layers
would have to be decoded, buffered by two totally separate passes, the
apparent syntactic commonality is going to be more confusing than
valuable.

For the transport layer, consider a simple binary encoding such as
this in the per-cpu streams:

   timestamp [4 bytes]
   length [4 bytes]
   <raw-data>, padded to a 4-byte multiple

or something like the tag/length type markup used by TIFF.

But before getting too tricky on the timestamp angle, it would be
worthwhile to measure whether something as simple as using an
smp-shared atomic_t counter for a global message serial number, has
ping-pong overhead so high that it is impractical.  Sure relayfs has
"high performance", whatever that means, but if that's an order of
magnitude or few beyond what systemtap might reasonably exploit, then
let's just sacrifice some of that and KISS.

- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20050426/000bdc52/attachment.sig>