lkml.org 
[lkml]   [2008]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 1/3] Unified trace buffer

* 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


\
 
 \ /
  Last update: 2008-09-27 19:21    [from the cache]
©2003-2011 Jasper Spaans