diff options
author | Namhyung Kim <[email protected]> | 2024-02-27 21:33:35 -0800 |
---|---|---|
committer | Namhyung Kim <[email protected]> | 2024-02-29 13:53:56 -0800 |
commit | b44d66536859393772c67cb1da65345127f692e0 (patch) | |
tree | 4b0a7da48fdc47ae727eeef00f83bf2a7509dd18 /tools/perf/util/trace-event-scripting.c | |
parent | 97b6b4ac1c5dd42a473a4f8e775d97476c5da038 (diff) |
perf lock contention: Account contending locks too
Currently it accounts the contention using delta between timestamps in
lock:contention_begin and lock:contention_end tracepoints. But it means
the lock should see the both events during the monitoring period.
Actually there are 4 cases that happen with the monitoring:
monitoring period
/ \
| |
1: B------+-----------------------+--------E
2: B----+-------------E |
3: | B-----------+----E
4: | B-------------E |
| |
t0 t1
where B and E mean contention BEGIN and END, respectively. So it only
accounts the case 4 for now. It seems there's no way to handle the case
1. The case 2 might be handled if it saved the timestamp (t0), but it
lacks the information from the B notably the flags which shows the lock
types. Also it could be a nested lock which it currently ignores. So
I think we should ignore the case 2.
However we can handle the case 3 if we save the timestamp (t1) at the
end of the period. And then it can iterate the map entries in the
userspace and update the lock stat accordinly.
Signed-off-by: Namhyung Kim <[email protected]>
Reviewed-by: Ian Rogers <[email protected]>
Reviwed-by: Arnaldo Carvalho de Melo <[email protected]>
Cc: Song Liu <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Diffstat (limited to 'tools/perf/util/trace-event-scripting.c')
0 files changed, 0 insertions, 0 deletions