Re: tracepoint maintainance models

["Frank Ch. Eigler" <fche@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

Hi -

alan wrote:

> > Unless one's worried about planetary-scale energy use, I see no point
> > in multiplying overheads by "every box on the planet".
>
> Because we are all paying for your debug stuff we aren't
> using. Systems get slow and sucky by the death of a million cuts not
> by one stupid action.

"slow and sucky" happens one machine at a time.  One doesn't perceive
time that is "lost" by a random machine sitting in a hut somewhere
running a bit slower.


> > Unfortunately, cases in which this sort of out-of-band markup would be
> > sufficient are pretty much those exact same cases where it is not
> > necessary.  Remember, the complex cases occur when the compiler munges
> > up control flow and data accessability, so debuginfo cannot or does
> > not correctly place the probes and their data gathering compatriots.
> 
> Which if understand you right you'd end up unmunging and reducing
> performance for by reducing the options gcc has to make that critical
> code go fast just so you know what register something is living in.

Something like that, but not as drastic.  The effect of a marker would
be to force the compiler to preserve a statement boundary and or
preserve or recreate the values when the marker is active.  It may
interfere with the otherwise optimized code somewhat, but the amount
depends on the details.  For the most time-critical probes, we could
opt for the least powerful/disruptive markers.

- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]