[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1375727010.22073.110.camel@gandalf.local.home>
Date: Mon, 05 Aug 2013 14:23:30 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: "H. Peter Anvin" <hpa@...ux.intel.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>, gcc <gcc@....gnu.org>,
Ingo Molnar <mingo@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Thomas Gleixner <tglx@...utronix.de>,
David Daney <ddaney.cavm@...il.com>,
Behan Webster <behanw@...verseincode.com>,
Peter Zijlstra <peterz@...radead.org>,
Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [RFC] gcc feature request: Moving blocks into sections
On Mon, 2013-08-05 at 11:17 -0700, H. Peter Anvin wrote:
> On 08/05/2013 10:55 AM, Steven Rostedt wrote:
> >
> > Well, as tracepoints are being added quite a bit in Linux, my concern is
> > with the inlined functions that they bring. With jump labels they are
> > disabled in a very unlikely way (the static_key_false() is a nop to skip
> > the code, and is dynamically enabled to a jump).
> >
>
> Have you considered using traps for tracepoints? A trapping instruction
> can be as small as a single byte. The downside, of course, is that it
> is extremely suppressed -- the trap is always expensive -- and you then
> have to do a lookup to find the target based on the originating IP.
No, never considered it, nor would I. Those that use tracepoints, do use
them extensively, and adding traps like this would probably cause
heissenbugs and make tracepoints useless.
Not to mention, how would we add a tracepoint to a trap handler?
-- Steve
--
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