[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
2008/11/12 Ingo Molnar <>:
> * Frederic Weisbecker <> wrote:
>> Impact: remove spinlocks and irq disabling in function return tracer.
>> I've tried to figure out all of the race condition that could happen when
>> the tracer pushes or pops a return address trace to/from the current
>> thread_info.
>> Theory:
>> _ One thread can only execute on one cpu at a time. So this code doesn't need
>> to be SMP-safe. Just drop the spinlock.
>> _ The only race could happen between the current thread and an interrupt. If an
>> interrupt is raised, it will increase the index of the return stack storage and
>> then execute until the end of the tracing to finally free the index it used.
>> We don't need to disable irqs.
>> This is theorical. In practice, I've tested it with a two-core SMP
>> and had no problem at all. Perhaps -tip testing could confirm it.
>> Signed-off-by: Frederic Weisbecker <>
>> Cc: Steven Rostedt <>
> applied to tip/tracing/function-return-tracer, thanks Frederic!
> Ingo

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?

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