Re: static instrumentation for kernel

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

Hi -

> [...]
> >    SYSTEMTAP_PROBE(name) 
> >    SYSTEMTAP_PROBE_N(name,arg1) // arg1 castable to int64_t numeric
> >    SYSTEMTAP_PROBE_NS(name,arg1,arg2) // arg2 castable to char* string
> >

> It seems to somehow limit the variations of parameters that can be
> passed as argument : one could need a particular macro for a
> (int64_t,void*,int32_t,byte).  We can imagine thousands of
> variations. Or maybe the goal is just to allow a small subset of
> types ?

Since systemtap uses (approximately) only two data types, the
combinatorial explosion is not so bad.  Integers and pointers are
castable to int64_t, and char* strings can get passed as is.  So we
would have 2 ** (maximum-arity) macros to generate, say 256.


> [...]
> SYSTEMTAP_PROBE3(name,arg1,arg2,arg3)  and so on..
> But I'm afraid I can't figure out how to make this work with typeof().

Yeah, typeof() / __builtin_types_compatible_p() is a compile-time (not
preprocessor-time) constant expression.  If one could count on the
compiler removing all code (including the static function pointer)
from the false branches of such compile-time type tests, then it may
"just work" to emit N 2**N-long macros.


> The problem with the if() { call } scheme comes when you want to
> deactivate the probe. [...]  When the probe is removed, a thread
> could clearly end up calling a bad function pointer by being stalled
> between the if and the call. [...]

Thanks for pointing out that such concurrency issues have to be
investigated.  Since session startup/shutdown is not as time critical
as probe execution is, something as conservative as the
djprobes-inspired IPI/quiescence could do the trick here.


> > [...] The indirect call would be somewhat slower but much simpler
> > than a djprobe, and much faster than a kprobe.  [...]

> But still slower than an inlined function. Inlining has this
> interesting point: it doesn't have to build up the function call by
> putting the arguments on the stack and does not do the call itself.

Indeed, but if the code to be inlined is to be changeable (i.e., let
the user write an arbitrary probe handler), then this can't work
without kernel recompilation/rebooting each time.


> If you want to do static tracing, you should really investigate the
> fastest solutions available.

The thing is, I don't just want to do *tracing*.


> [...]  And did I say that we have a modular trace viewer (LTTV) ?

Emitting data in a compatible form could be very useful for systemtap
users.


- FChE