b44d665368
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 <namhyung@kernel.org>
Reviewed-by: Ian Rogers <irogers@google.com>
Reviwed-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Song Liu <song@kernel.org>
Cc: bpf@vger.kernel.org
Link: https://lore.kernel.org/r/20240228053335.312776-1-namhyung@kernel.org
|
||
|---|---|---|
| .. | ||
| vmlinux | ||
| .gitignore | ||
| augmented_raw_syscalls.bpf.c | ||
| bench_uprobe.bpf.c | ||
| bperf_cgroup.bpf.c | ||
| bperf_follower.bpf.c | ||
| bperf_leader.bpf.c | ||
| bperf_u.h | ||
| bpf_prog_profiler.bpf.c | ||
| func_latency.bpf.c | ||
| kwork_top.bpf.c | ||
| kwork_trace.bpf.c | ||
| lock_contention.bpf.c | ||
| lock_data.h | ||
| off_cpu.bpf.c | ||
| sample_filter.bpf.c | ||
| sample-filter.h | ||