Re: "lttng comparison with other tracers" page

[Mathieu Desnoyers <compudj at krystal dot dyndns dot org>]

* Frank Ch. Eigler (fche@redhat.com) wrote:
> 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.
> 

Have you measured the performance impact of disabling interrupts around
the probe ?

Basically, it sounds like you are shipping a car without brakes nor air
bags simply because it makes the car too heavy and therefore too slow. I
don't think trading stability and robustness for speed is a good
tradeoff.

Mathieu

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

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68