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