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