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

    * Linus Torvalds <> 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.


     \ /
      Last update: 2008-09-27 19:21    [W:0.021 / U:53.104 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site