[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090314164358.GB31930@elte.hu>
Date: Sat, 14 Mar 2009 17:43:58 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Steven Rostedt <rostedt@...dmis.org>,
ltt-dev@...ts.casi.polymtl.ca,
Peter Zijlstra <peterz@...radead.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Arjan van de Ven <arjan@...radead.org>,
Pekka Paalanen <pq@....fi>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, Martin Bligh <mbligh@...gle.com>,
"Frank Ch. Eigler" <fche@...hat.com>,
Tom Zanussi <tzanussi@...il.com>,
Masami Hiramatsu <mhiramat@...hat.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Jason Baron <jbaron@...hat.com>,
Christoph Hellwig <hch@...radead.org>,
Jiaying Zhang <jiayingz@...gle.com>,
Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>,
mrubin@...gle.com, md@...gle.com
Subject: Re: [RFC patch 00/41] LTTng 0.105 core for Linux 2.6.27-rc9
* Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> wrote:
> * Ingo Molnar (mingo@...e.hu) wrote:
> >
> > * Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> wrote:
> >
> > > > Let me give you a few examples of existing areas of overlap:
> > > >
> > > > > The corresponding git tree contains also the trace clock
> > > > > patches and the lttng instrumentation. The trace clock is
> > > > > required to use the tracer, but it can be used without the
> > > > > instrumentation : there is already a kprobes and userspace
> > > > > event support included in this patchset.
> > > >
> > > > The latest tracing tree includes
> > > > kernel/tracing/trace_clock.c which offers three trace clock
> > > > variants, with different performance/precision tradeoffs:
> > > >
> > > > trace_clock_local() [ for pure CPU-local tracers with no idle
> > > > events. This is the fastest but least
> > > > coherent tracing clock. ]
> > > >
> > > > trace_clock() [ intermediate, scalable clock with
> > > > usable but imprecise global coherency. ]
> > > >
> > > > trace_clock_global() [ globally serialized, coherent clock.
> > > > It is the slowest but most accurate variant. ]
> > > >
> > > > Tracing plugins can pick their choice. (This is relatively new
> > > > code but you get the idea.)
> > > >
> > >
> > > Hehe this reminds me of the trace clock thread I started a few
> > > months ago on LKML. So you guys took over that work ? Nice :)
> > > Is it based on the trace-clock patches I proposed back then ?
> > > Ah, no. Well I guess we'll have to discuss this too. I agree
> > > on the trace_clock_local/trace_clock/trace_clock_global
> > > interface, it looks nice. The underlying implementation will
> > > have to be discussed though.
> >
> > Beware: i found the assembly trace_clock() stuff you did back
> > then rather ugly ;-) I dont think there's any easy solutions
> > here, so i went for this palette of clocks.
> >
>
> Hi Ingo,
>
> I agree for the palette of clocks to fit all needs. I wonder
> what exactly you found ugly in the approach I took with my
> trace_clock() implementation ? Maybe you could refresh my
> memory, I do not recall writing any part of it in assembly.. ?
> But this is a whole different topic. We can discuss this
> later.
hm, it was months ago. Ok, it must have been this one:
http://lkml.org/lkml/2008/11/7/21
http://lkml.org/lkml/2008/11/7/23
indeed no assembly but almost ;-) What i found rather ugly were
the cnt32_to_63() complications.
Ingo
--
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