diff options
| author | Frederic Weisbecker <[email protected]> | 2009-04-06 01:49:33 +0200 |
|---|---|---|
| committer | Ingo Molnar <[email protected]> | 2009-04-10 12:50:56 +0200 |
| commit | 2062501ae6505dbc5bff3a792246c2661d114050 (patch) | |
| tree | 59792987c9e9fd1ae657c2e4a5cdb14545523e24 /tools/perf/scripts/python | |
| parent | 1cad1252ed279ea59f3f8d3d3a5817eeb2f7a4d3 (diff) | |
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 <[email protected]>
Acked-by: Peter Zijlstra <[email protected]>
Cc: Steven Rostedt <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions