[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1158596341.6069.130.camel@localhost.localdomain>
Date: Mon, 18 Sep 2006 17:19:01 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Ingo Molnar <mingo@...e.hu>
Cc: "Frank Ch. Eigler" <fche@...hat.com>,
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
Ar Llu, 2006-09-18 am 17:22 +0200, ysgrifennodd Ingo Molnar:
> yeah - but i think to make it easier for SystemTap to insert a
> low-overhead probe there needs to be a 5-byte NOP inserted. There wont
> be any function call or condition at that place. At most there will be
> some minimal impact on the way gcc compiles the code in that function,
And more L1 misses. It seems that this problem should be solved by
jprobes and your int3 optimisation work.
> SystemTap. For example at the point of the probe gcc might already have
> destroyed a register-passed function parameter.
So its L1 misses more register reloads and the like. Sounds more and
more like wasted clock cycles for debug. Most of these watchpoints will
run billions of times a day on millions of machines none of whom are
using any debugging. You are optimising the corner case (in the extreme
in fact). Its one thing to dump trace helper data into the kernel, its
another when we all get to pay for it all the time when we don't need to
(or we compile it out at which point it offers nothing anyway).
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists