This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Review of LKST probe points


Hi, Will -


> I reviewed where LKST puts the various instrumentation points it
> provides.  [...]

Thanks!


> [...]
> The "*" and "**" means there are some issues that need to be addressed 
> to get probe point, e.g. instrumentation is in inlined function or in 
> the middle of a function.

Inlined functions are not a big problem, assuming dwarf decoding.
Each supplied probe would just get "forked" for each actual inlining
point.  Function interior probe points are likewise made possible via
dwarf, but the task of conveniently specifying the insertion point
remains.  An explicit marker in the object code is of course one
option, but would require kernel changes with all the controversy that
usually entails.


> LKST Event
> PROCESS_CONTEXTSWITCH	**inline function context_switch, if it wasn't
> 			** probe kernel.function("context_switch")

In case it's not obvious, it would be reasonable to expose these
standardized tracing points to systemtap as an additional "coordinate
system"

        probe lkst(PROCESS_CONTEXTSWITCH) { ... }

so a user does not have to map them explicitly.

> [...]
> TIMER_ADD		** in middle timer_on(), between spinlock/unlock

Is the precise placement of the probe point within a locking sequence
like this important?  What effect would putting the probe past that
last unlock have?


> [...]
> /* LKST management events */
> LKST_INIT
> LKST_KERNEL_DUMP

Can you outline what these are for?


> [...]
> Implemented in LKST in inline functions:
> 
> LK_SPINLOCK
> LK_SPINTRYLOCK
> LK_SPINUNLOCK
> [...]

I believe the systemtap scripts will need access to such primitives
too, though restricted in such a way that they can't screw up the
system.  For example, a spinlock-protected structure may need a lock
on an SMP host, which in systemtap may get expressed declaratively,
something like this new control structure:

   probe foo {
     spinlock ($var)
       { 
         /* ... */
       }
   }

and expanded to a nonblocking construct such as this:

      {
        if (! spin_trylock_irqsave (& VAR, flags))
          { ++ probe_locking_abort; return; }

        /* ... */

        spin_unlock_irqrestore (& VAR, flags)
      }

Given debuginfo data, systemtap may be able to infer which of the many
kinds of lock $var is (checking whether its type is spinlock_t, etc.)
and implicitly use the correct underlying functions.  That would allow
use of a generalized "lock" control structure instead of multiple
explicit "spinlock", "semaphorelock", etc. ones.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]