Re: Evaluating SystemTap for Network Response Times

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

> >I hope it is exactly this kind of complex instrumentation with which
> >systemtap could show its prowess.  I would like to help you make it
> >work.
> >  
> So should I take this as a volunteering of your assistance in answering 
> questions? :)  

Absolutely.

> [...] Before I start tracing the 2.6.x kernel for the places we want
> to instrument this network study I wondered - hve you guys had
> already started a "tapset" for this issue?

In connection with their binary trace prototype, the Hitachi folks
have posted some tapset scripts that define network layer probes.
(http://sourceware.org/ml/systemtap/2005-q4/msg00446.html).  But we
don't have enough to even call it a start yet.


> The other question I had was if SystemTap intends to look into
> djprobes in the future.  [...]

We would like Hitachi to finish a djprobes implementation that
performs applicability tests in the kernel, as a hidden part of the
kprobes api.  In this case, it'd be a kprobes-layer optimization that
systemtap need not be aware of.  Alternately, if they write user-level
analysis algorithms, we can put those into the translator and bypass
kprobes outright for applicable probe points.


> [...] From our studies, it's a lot lighter weight than kprobes and
> we're hoping to go with something like SystemTap so that in the
> future you guys might implement a way for users to choose which
> probe they want at insert time.

Would you folks use static instrumentation too, if it were available
for systemtap?  That is, would you be willing to insert macro calls
into your kernel sources, which would get roughly djprobes-level
performance for enabled probes, and a slight slowdown for disabled
ones?
(http://sourceware.org/ml/systemtap/2005-q4/msg00415.html)

- FChE