Messages in this thread | | | Date | Thu, 25 Sep 2008 23:16:54 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |