[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090311183231.GA24106@elte.hu>
Date: Wed, 11 Mar 2009 19:32:31 +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:
> > 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.
> > This approach works for all your other patches as well. A
> > direct, constructive comparison and active work on unifying
> > them is required.
>
> Yes, let's try to do it. Maybe it's better to start a new
> thread with less CCs for this type of work ?
Yeah. More finegrained steps are really needed.
The least controversial bits would be the many tracepoints you
identified in LTTng as interesting. Mind sending them separately
so that we can make some progress?
In the latest tracing code all tracepoints will show up
automatically under /debug/tracing/events/ and can be used by
user-space tools.
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