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

* Ingo Molnar <mingo@elte.hu> wrote:

> 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)

let me outline why that flip-flopping occured.

- coherent tracer: has built-in serialization of global events. If the
tracer shows events to be after each other, they were after each
other.

- incoherent tracer: events might be mixed up slightly on the micro
scale.

In your tree you'll see dozens of fixes from me in the past 10 years or
so where i used various tracers to find some bug. Some of them were done
with coherent tracers, some of them were done with incoherent tracers.

Here a few common patterns that influenced which kind of tracer i used:

- SMP races. There it's really important to see the ordering of events,
and coherent tracers (where the ordering of events as displayed by
the tracer can be trusted) are used by default

- EXCEPT: _very_ often an SMP race goes away if we add global
synchronization to trace events. Sometimes the pure delay can hide
races. So incoherent tracers are very important here.

- analysis of performance problems: here incoherent tracers win hands
down. It's important to see all events on all CPUs, but it's not at
all important to see the precise micro-ordering of events on a global
basis. We want to see rough workload behavior, how tasks iteract -
and most importantly, we want tracing to be as low-overhead as
possible.

- [ in many cases coherency does not matter because we only look at a
single CPU's or app's trace. ]

for example on an 16-way CPU, when i run a high-event-count workload and
add global serialization to events, the workload can easily be slower by
10% or more. Sometimes even the characteristics of the workload changes
due to having a globally synchronized tracer.

So ... neither coherent nor incoherent tracers are a clear, obvious
default.

IMO incoherent is the more useful default in terms of being able to find
bugs with it, because it has a higher utility factor. People have to
interpret traces anyway, and the main usecase of ftrace is that i ask a
tester to do a trace, and then i interpret it.

Coherent is the more fool-proof default - but less generally usable.

ftrace was coherent not so long ago - so we can certainly switch back to
that, as a default. But coherency must not be hardcoded into a multi-CPU
tracer.

Since the overhead and serialization skew shows up very quickly in
ftrace we do not serialize globally and use cpu_clock() and try to make
that accurate enough.

But in any case, cpu_clock()/sched_clock() is non-serialized, so it can
be used in coherent and non-coherent tracers just as well. So i dont see
the fundamental connection.

Ingo


\
 
 \ /
  Last update: 2008-09-27 19:53    [W:0.706 / U:0.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site