"lttng comparison with other tracers" page

[Frank Ch. Eigler]

Mathieu Desnoyers <compudj@krystal.dyndns.org> writes:

> [...]
>> I looked at it for a while, but I couldn't determine anything more than
>> simple interrupt-reentrance.  The above tracepoints are hit often enough
>> that even a low-rate of reentrance will add up quickly.
>> 
>> I did add a "-DINTERRUPTIBLE=0" option to disable interrupts during our
>> handlers, which eliminated the problem as far as I could see.
>
> Hrm, the systemtap code should always expect reentrancy coming from
> interrupts. The way to deal with this is either to _always_ disable
> interrupts around the probe code, 

This is possible, but does negatively impact overall
latency/performance, so we no longer do it by default.  There is a
gross knob (-DINTERRUPTIBLE=0) but we could make it more fine-grained.

> or to use atomic operations within the probe and allow nested probe
> execution at any given point of the probe.

This may work for a plain tracer that carries no state from probe to
probe, but in our case a script may possess locks on global variables
and be mid-computation, so complete reentrancy is not possible.

In our case, the simplest solution may be to raise or eliminate the
skipped probe limit.


- FChE