[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240830065150.1758962-3-namhyung@kernel.org>
Date: Thu, 29 Aug 2024 23:51:50 -0700
From: Namhyung Kim <namhyung@...nel.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>,
Ian Rogers <irogers@...gle.com>,
Kan Liang <kan.liang@...ux.intel.com>
Cc: Jiri Olsa <jolsa@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-perf-users@...r.kernel.org,
Song Liu <song@...nel.org>,
bpf@...r.kernel.org
Subject: [PATCH 3/3] perf lock contention: Do not fail EEXIST for update
When it updates the lock stat for the first time, it needs to create an
element in the BPF hash map. But if there's a concurrent thread waiting
for the same lock (like for rwsem or rwlock), it might race with the
thread and possibly failed to update with -EEXIST. In that case, it can
lookup the map again and put the data there instead of failing.
Signed-off-by: Namhyung Kim <namhyung@...nel.org>
---
tools/perf/util/bpf_skel/lock_contention.bpf.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/tools/perf/util/bpf_skel/lock_contention.bpf.c b/tools/perf/util/bpf_skel/lock_contention.bpf.c
index 4b7237e178bd..52a876b42699 100644
--- a/tools/perf/util/bpf_skel/lock_contention.bpf.c
+++ b/tools/perf/util/bpf_skel/lock_contention.bpf.c
@@ -491,6 +491,12 @@ int contention_end(u64 *ctx)
err = bpf_map_update_elem(&lock_stat, &key, &first, BPF_NOEXIST);
if (err < 0) {
+ if (err == -EEXIST) {
+ /* it lost the race, try to get it again */
+ data = bpf_map_lookup_elem(&lock_stat, &key);
+ if (data != NULL)
+ goto found;
+ }
if (err == -E2BIG)
data_map_full = 1;
__sync_fetch_and_add(&data_fail, 1);
@@ -498,6 +504,7 @@ int contention_end(u64 *ctx)
goto out;
}
+found:
__sync_fetch_and_add(&data->total_time, duration);
__sync_fetch_and_add(&data->count, 1);
--
2.46.0.469.g59c65b2a67-goog
Powered by blists - more mailing lists