This is the mail archive of the systemtap@sourceware.org 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: adding statements in alias definition as epilogue


Guang Lei Li <liguangl@cn.ibm.com> writes:

> [...]
> probe addevent.tskdispatching.* {}
>
> will cause both addevent.tskdispatch.cpuidle.backtrace & 
> addevent.tskdispatch.cpuidle to be triggered.

Actually, it doesn't: the wildcard only consumes one component of the
probe point name.


> > This assumes that per-probe backtrace configuration makes more sense
> > than, say, a single global variable.
> 
> 'backtrace' used inside the probe definitions is a local variable, which 
> is cheaper than using a global variable.

Only slightly (one extra shared lock).

> And it also enables to turn on/off backtrace for each event
> separately instead of turn on/off all backtraces as a whole.

I see that, but is this capability important & useful?  Plus, apropos
an earlier message, how does the concept of high-performance binary
tracing mesh at all with slow and bulky backtrace generation?


> [...]  Besides my specific need of alias definition as epilogue, I
> think it is also useful if you want a filter: [...]
>
> probe derived_probe := alias_with_filter_codes  {
>    filter_on = 1
>    scsi_lun = 2
>    scsi_dev_major = 3
> }

This style of usage could be accommodated with explicit code
(analogous to "if (target() != pid()) next") instead of alias epilogues.


- FChE


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