Systemtap-UTT status

Systemtap-UTT status

[Martin Hunt]

I had a lot of bug-hunting to do, but I now have UTT-enabled systemtap
running stably on x86 and x86_64, as well as kernel rpms containing the
utt kernel code.  The next step is to integrate it into staprun so it
doesn't require strange invocations such as 
"stap -l -o - foo.stp | stp_parse -i -"

stp_parse needs completely rewritten and should be integrated in
staprun. With some work it should be possible to integrate it seamlessly
so UTT would always be used automatically when present, otherwise the
current procfs/relayfs would be used.

Performance is very good, better than procfs and almost equal to
relayfs.  I see some areas for small improvement in the sources. It
works well in realtime mode, although I won't know about speed there
until I do a rewrite of stp_parse. 

It looks like we could ditch the current relayfs and procfs transports
in favor of UTT. We would still have the "-b" batch option for stap,
which would leave the output in per-cpu files, but UTT would always be
used. 

PROS: Shared code with blktrace (and others??). Moving the code to the
kernel makes our modules a bit simpler. Excellent performance. 

CONS: Need to support 3 transports for a while. UTT isn't in any kernel
yet. Userspace code all needs rewritten.