[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <450B0BF9.8090407@opersys.com>
Date: Fri, 15 Sep 2006 16:24:25 -0400
From: Karim Yaghmour <karim@...rsys.com>
To: Andrew Morton <akpm@...l.org>
CC: Alan Cox <alan@...rguk.ukuu.org.uk>,
Roman Zippel <zippel@...ux-m68k.org>,
Tim Bird <tim.bird@...sony.com>, Ingo Molnar <mingo@...e.hu>,
Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
linux-kernel@...r.kernel.org,
Christoph Hellwig <hch@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Greg Kroah-Hartman <gregkh@...e.de>,
Thomas Gleixner <tglx@...utronix.de>,
Tom Zanussi <zanussi@...ibm.com>, ltt-dev@...fik.org,
Michel Dagenais <michel.dagenais@...ymtl.ca>
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108
Andrew Morton wrote:
> People have been speeding up kprobes in recent kernels, to avoid the int3
> overhead. I don't recall seeing how effective that has been.
I don't want to microdebate this one, but here's the quote from Frank
on the topic of djprobe:
> Smart teams from IBM and Hitachi have been hammering away at this code
> for a year or two now, and yet (roughly) here we are. There have been
> experiments involving plopping branches instead of int3's at probe
> locations, but this is self-modifying code involving multiple
> instructions, and appears to be tricky on SMP/preempt boxes.
The idea behind this mechanism is neat. But every step along the way
there seem to be ever more complex corner cases where it can't be
used.
Should this mechanism ever be made to work, the need for static
markup would still be felt however.
Karim
-
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