[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0609152046350.6761@scrub.home>
Date: Fri, 15 Sep 2006 21:10:44 +0200 (CEST)
From: Roman Zippel <zippel@...ux-m68k.org>
To: Ingo Molnar <mingo@...e.hu>
cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
"Frank Ch. Eigler" <fche@...hat.com>, karim@...rsys.com,
Tim Bird <tim.bird@...sony.com>,
Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
linux-kernel@...r.kernel.org,
Christoph Hellwig <hch@...radead.org>,
Andrew Morton <akpm@...l.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
Hi,
On Fri, 15 Sep 2006, Ingo Molnar wrote:
> > Ar Gwe, 2006-09-15 am 13:08 -0400, ysgrifennodd Frank Ch. Eigler:
> > > Alan Cox <alan@...rguk.ukuu.org.uk> writes:
> > > - where 1000-cycle int3-dispatching overheads too high
> >
> > Why are your despatching overheads 1000 cycles ? (and if its due to
> > int3 why are you using int 3 8))
>
> this is being worked on actively: there's the "djprobes" patchset, which
> includes a simplified disassembler to analyze common target code and can
> thus insert much faster, call-a-trampoline-function based tracepoints
> that are just as fast as (or faster than) compile-time, static
> tracepoints.
Who is going to implement this for every arch?
Is this now the official party line that only archs, which implement all
of this, can make use of efficient tracing?
bye, Roman
-
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