lkml.org 
[lkml]   [2008]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateThu, 25 Sep 2008 23:16:54 +0200
FromIngo Molnar <>
SubjectRe: [RFC PATCH 1/3] Unified trace buffer

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

> ftrace has the same robustness design as lockdep has: as little
> external infrastructure dependencies as possible. And lockdep has
> recursion checks too, and excessive amounts of paranoia all around the
> place.
>
> Ftrace has the same robustness philosophy too, and yes, despite that
> we judged cpu_clock() to be worth the risk, because accurate and fast
> timestamps are a feature and we didnt want to duplicate.

and note that there's another pragmatic argument: often we notice
cpu_clock() bugs by looking at traces. I.e. people fixing trace
timestamps _fix the scheduler_. Sometimes it is very hard to notice
scheduling artifacts that happen due to small inaccuracies in
cpu_clock().

so there's continuous coupling between precise scheduling and good trace
timestamps. I'd be willing to pay a lot more for that than the few
(rather obvious...) robustness problems we had with sched_clock() in the
past.

anyway ... i'm not _that_ attached to the idea, we can certainly go back
to the original ftrace method of saving raw TSC timestamps and
postprocessing. I think users will quickly force us back to a more
dependable clock, and if not then you were right and i was wrong ;-)

In fact even when we used sched_clock() there were some artifacts: as
you pointed it out we dont want to do per event cross-CPU
synchronization by default as that is very expensive. Some people wanted
GTOD clock for tracing and we very briefly tried that - but that was an
utter maintenance nightmare in practice.

Ingo


\
 
 \ /
  Last update: 2008-09-25 23:21    [from the cache]
©2003-2010