This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: "lttng comparison with other tracers" page
- From: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Josh Stone <jistone at redhat dot com>, systemtap at sources dot redhat dot com, pierre-marc dot fournier at polymtl dot ca, michel dot dagenais at polymtl dot ca
- Date: Wed, 18 Mar 2009 11:14:55 -0400
- Subject: Re: "lttng comparison with other tracers" page
- References: <20090312232557.GA16297@redhat.com> <20090314025858.GD22526@Krystal> <20090314122841.GB12974@redhat.com> <20090314145053.GA8830@Krystal> <20090317190243.GH12974@redhat.com> <20090317204131.GA19431@Krystal> <20090317210530.GJ12974@redhat.com> <49C049D2.4020503@redhat.com> <20090318011920.GA26367@Krystal> <y0mljr2q3nb.fsf@ton.toronto.redhat.com>
* 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