diff options
author | Frederic Weisbecker <fweisbec@gmail.com> | 2009-04-06 01:49:33 +0200 |
---|---|---|
committer | Ingo Molnar <mingo@elte.hu> | 2009-04-10 12:50:56 +0200 |
commit | 2062501ae6505dbc5bff3a792246c2661d114050 (patch) | |
tree | 59792987c9e9fd1ae657c2e4a5cdb14545523e24 /arch | |
parent | 1cad1252ed279ea59f3f8d3d3a5817eeb2f7a4d3 (diff) | |
download | op-kernel-dev-2062501ae6505dbc5bff3a792246c2661d114050.zip op-kernel-dev-2062501ae6505dbc5bff3a792246c2661d114050.tar.gz |
tracing/lockdep: report the time waited for a lock
While trying to optimize the new lock on reiserfs to replace
the bkl, I find the lock tracing very useful though it lacks
something important for performance (and latency) instrumentation:
the time a task waits for a lock.
That's what this patch implements:
bash-4816 [000] 202.652815: lock_contended: lock_contended: &sb->s_type->i_mutex_key
bash-4816 [000] 202.652819: lock_acquired: &rq->lock (0.000 us)
<...>-4787 [000] 202.652825: lock_acquired: &rq->lock (0.000 us)
<...>-4787 [000] 202.652829: lock_acquired: &rq->lock (0.000 us)
bash-4816 [000] 202.652833: lock_acquired: &sb->s_type->i_mutex_key (16.005 us)
As shown above, the "lock acquired" field is followed by the time
it has been waiting for the lock. Usually, a lock contended entry
is followed by a near lock_acquired entry with a non-zero time waited.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
LKML-Reference: <1238975373-15739-1-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'arch')
0 files changed, 0 insertions, 0 deletions