Message-ID: <20090314165936.GA11928@Krystal>
Date:	Sat, 14 Mar 2009 12:59:36 -0400
From:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	mrubin@...gle.com, Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Pekka Paalanen <pq@....fi>, "H. Peter Anvin" <hpa@...or.com>,
	md@...gle.com, Tom Zanussi <tzanussi@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	ltt-dev@...ts.casi.polymtl.ca,
	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, Martin Bligh <mbligh@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [ltt-dev] [RFC patch 00/41] LTTng 0.105 core for Linux
	2.6.27-rc9

* Ingo Molnar (mingo@...e.hu) wrote:
> 
> * 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.
> 

The fact that I put a patch touching cnt32_to_63 back then was just a
way to point out how the current cnt32_to_63 implementation is broken
for SMP and should stay in UP-only architecture-specific code (that was
an answer to Peter Zijlstra's reuse concerns). Once I got agreement that
tracers should not be expected to use cnt32_to_63, I dropped any patch
touching this piece of infrastructure and stayed with my
trace-clock-32-to-64.c implementation, which is SMP-safe, scalable and
basically extends atomically (through a rcu-like algorithm) a N bit
clock to a full 64-bits clock. This is very, very useful for lots of
architectures. Is it that code you find ugly ?

Mathieu

> 	Ingo
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev@...ts.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
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