Re: [RFC PATCH 1/3] Unified trace buffer

[Ingo Molnar <mingo@elte.hu>]

* 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