* Frédéric Weisbecker <fweisbec@gmail.com> wrote:

quoted text
> BTW I'm wondering about consistency in time capturing. When I look 
> into kernel/sched_clock.c I see this in introduction:
> 
> "The clock: sched_clock_cpu() is monotonic per cpu, and should be 
> somewhat consistent between cpus (never more than 2 jiffies 
> difference)."
> 
> Two Jiffies, that could result in a lot of inconsistency in the way 
> of nanosec capturing. The current task can be preempted between the 
> call time and the return time and I'm doing a 
> cpu_clock(raw_smp_processor_id) on these two times. Should I keep 
> the same processor_id for these two captures? But what would happen 
> if this cpu is shut down between these two times? One other solution 
> would be to plan time capture in usec but I would mostly lose the 
> interest of function cost measuring....
> 
> What do you think?

in practice the jitter is much lower - a couple of microseconds - up 
to a few dozen at most.

But it's a possibility, and i think the best solution is something 
that Steve suggested yesterday: a /debug/tracing/trace_options flag 
that turns on global ordering for tracing timestamps. Something like:

  echo global_timestamps > /debug/tracing/trace_options

tracers could also change the default of this flag. The function-cost 
tracer will probably want to default to globally synchronous 
timestamps, while the preempt and irqsoff tracers want to default to 
local timestamps only.

Would something like this work for you?

	Ingo
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/