[lkml]   [2008]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2] tracing/function-return-tracer: Make the function return tracer lockless

* Frédéric Weisbecker <> wrote:

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2008-11-13 09:59    [W:0.067 / U:1.692 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site