Re: Output Redesign in SystemTap Runtime

[Martin Hunt <hunt at redhat dot com>]

On Tue, 2005-04-26 at 17:26 -0400, Frank Ch. Eigler wrote:

> > [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.

Which gets us back to where we are now. The whole point of my proposal
was about tagging data.  The above works for timestamps, but as a
minimum, I am trying to do deferred symbolic lookups on addresses,
primarily in stack data. I'm asserting:

1. tags would be really useful.
2. If we implement them right, they will be safe to use for timestamps
too.

The difficulty, as you correctly pointed out, is that data could look
like our tags.  This could happen in situations like
A. We are recording data a process reads and it reads html, sgml, xml,
or worse, systemtap output.
B. The script writer deliberately creates it with something like
stp_printf( "<stack ...");
C. Some pointer in the kernel is pointing to non-user data that looks
like a tag and the script prints the pointer's target.

I had considered A and B.  A can be handled by modifying our
copy_from_user() functions. B can be handled by telling script writers
to not do that.  C I thought of yesterday and I don't know if it is a
real problem or not, but it worries me.

An alternative would be to run all string output to the transport
through a conversion function, except for special functions that tag
data, such as stp_print_stack(). But this breaks, for example, when you
save a stack as a string to a map, then later print it. There are
workarounds for this, but it could get ugly.

> 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.

I still need to do some research on monotonic timestamps on SMP systems.
I'll compare it with the counter.  Timestamps are more useful, but maybe
are not always required.

Martin