linux-kernel - Re: tracepoint maintainance models

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 Sep 2006 14:05:10 -0400
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Ingo Molnar <mingo@...e.hu>, Paul Mundt <lethal@...ux-sh.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jes Sorensen <jes@....com>, Andrew Morton <akpm@...l.org>,
	Tom Zanussi <zanussi@...ibm.com>,
	Richard J Moore <richardj_moore@...ibm.com>,
	Michel Dagenais <michel.dagenais@...ymtl.ca>,
	Christoph Hellwig <hch@...radead.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	William Cohen <wcohen@...hat.com>,
	"Martin J. Bligh" <mbligh@...igh.org>
Subject: Re: tracepoint maintainance models

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

Content of type "application/pgp-signature" skipped