From mboxrd@z Thu Jan  1 00:00:00 1970
From: mingo@elte.hu (Ingo Molnar)
Date: Sat, 14 Mar 2009 17:43:58 +0100
Subject: [ltt-dev] [RFC patch 00/41] LTTng 0.105 core for Linux
	2.6.27-rc9
In-Reply-To: <20090313161838.GA2925@Krystal>
References: <20090305224728.947235917@polymtl.ca>
	<20090306101142.GA26659@elte.hu> <20090306190224.GF14236@Krystal>
	<20090311183231.GA24106@elte.hu> <20090313161838.GA2925@Krystal>
Message-ID: <20090314164358.GB31930@elte.hu>


* Mathieu Desnoyers <mathieu.desnoyers at polymtl.ca> wrote:

> * Ingo Molnar (mingo at elte.hu) wrote:
> > 
> > * Mathieu Desnoyers <mathieu.desnoyers at polymtl.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