Re: [RFC PATCH 1/3] Unified trace buffer

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Fri, 26 Sep 2008, Ingo Molnar wrote:
> > 
> > i do not understand this argument of yours. (really)
> > 
> > 1) is your point that we might lock up?
> 
> Have you at all followed the discussion about the people who asked for 
> cross-CPU ordering? They wanted not timestamps at all, but global 
> atomic counter updates. Which is very reasonable, if timestamps don't 
> work (and jiffies certainly doesn't, especially in a NOHZ 
> environment).
> 
> IOW, my whole argument is that what tracers want is _not_ the same 
> thing as what "sched_clock()" wants.

ah, i see what you mean. I think that's an orthogonal property.

Well, it's important in some cases, not that important in other cases.

Historically we've been flip-flopping on that issue in ftrace, whether 
it should be coherent by default or not. We had at least three of four 
variations of global synchronization. (one was an atomic generation 
counter, another variant a global lock)

Eventually people noticed the overhead and asked for it to be faster.

If all you do is to trace high-freq events on all CPUs and you are _not_ 
interested in the precise interactions, the overhead of global 
synchronization can hurt a lot.

In any case, SMP coherency of trace events is an independent property of 
the tracer, and preferably something that can be turned on/off.

	Ingo