tracing: do not grab lock in wakeup latency function tracing
commit478142c39c8c2f5f63038e5f2224e6729406e587
authorSteven Rostedt <srostedt@redhat.com>
Wed, 9 Sep 2009 14:36:01 +0000 (9 10:36 -0400)
committerSteven Rostedt <rostedt@goodmis.org>
Thu, 10 Sep 2009 03:54:04 +0000 (9 23:54 -0400)
tree222d3fc2fd8142299140d05206ada65b653e4a33
parentd8eeb2d3b26d25c44c10f28430e2157a2d20bd1d
tracing: do not grab lock in wakeup latency function tracing

The wakeup tracer, when enabled, has its own function tracer.
It only traces the functions on the CPU where the task it is following
is on. If a task is woken on one CPU but then migrates to another CPU
before it wakes up, the latency tracer will then start tracing functions
on the other CPU.

To find which CPU the task is on, the wakeup function tracer performs
a task_cpu(wakeup_task). But to make sure the task does not disappear
it grabs the wakeup_lock, which is also taken when the task wakes up.
By taking this lock, the function tracer does not need to worry about
the task being freed as it checks its cpu.

Jan Blunck found a problem with this approach on his 32 CPU box. When
a task is being traced by the wakeup tracer, all functions take this
lock. That means that on all 32 CPUs, each function call is taking
this one lock to see if the task is on that CPU. This lock has just
serialized all functions on all 32 CPUs. Needless to say, this caused
major issues on that box. It would even lockup.

This patch changes the wakeup latency to insert a probe on the migrate task
tracepoint. When a task changes its CPU that it will run on, the
probe will take note. Now the wakeup function tracer no longer needs
to take the lock. It only compares the current CPU with a variable that
holds the current CPU the task is on. We don't worry about races since
it is OK to add or miss a function trace.

Reported-by: Jan Blunck <jblunck@suse.de>
Tested-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
kernel/trace/trace_sched_wakeup.c