From: Tengda Wu <wutengda@huaweicloud.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: song@kernel.org, Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
kan.liang@linux.intel.com, linux-perf-users@vger.kernel.org,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org
Subject: [PATCH -next 2/2] perf stat: Fix incorrect display of bperf when event count is 0
Date: Wed, 25 Sep 2024 13:55:23 +0000 [thread overview]
Message-ID: <20240925135523.367957-3-wutengda@huaweicloud.com> (raw)
In-Reply-To: <20240925135523.367957-1-wutengda@huaweicloud.com>
There are 2 possible reasons for the event count being 0: not
supported and not counted. Perf distinguishes between these two
possibilities through `evsel->supported`, but in bperf, this value
is always false. This is because bperf is prematurely break or
continue in the evlist__for_each_cpu loop under __run_perf_stat(),
skipping the `counter->supported` assignment, resulting in bperf
incorrectly displaying <not supported> when the count is 0.
The most direct way to fix it is to do `evsel->supported` assignment
when opening an event in bperf. However, since bperf only opens
events when loading the leader, the followers are not aware of
whether the event is supported or not. Therefore, we store the
`evsel->supported` value in a common location, which is the
`perf_event_attr_map`, to achieve synchronization of event support
across perf sessions.
Fixes: 7fac83aaf2ee ("perf stat: Introduce 'bperf' to share hardware PMCs with BPF")
Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
---
tools/lib/perf/include/perf/bpf_perf.h | 1 +
tools/perf/util/bpf_counter.c | 18 ++++++++++--------
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/tools/lib/perf/include/perf/bpf_perf.h b/tools/lib/perf/include/perf/bpf_perf.h
index e7cf6ba7b674..64c8d211726d 100644
--- a/tools/lib/perf/include/perf/bpf_perf.h
+++ b/tools/lib/perf/include/perf/bpf_perf.h
@@ -23,6 +23,7 @@
struct perf_event_attr_map_entry {
__u32 link_id;
__u32 diff_map_id;
+ __u8 supported;
};
/* default attr_map name */
diff --git a/tools/perf/util/bpf_counter.c b/tools/perf/util/bpf_counter.c
index 3346129c20cf..c04b274c3c45 100644
--- a/tools/perf/util/bpf_counter.c
+++ b/tools/perf/util/bpf_counter.c
@@ -425,18 +425,19 @@ static int bperf_reload_leader_program(struct evsel *evsel, int attr_map_fd,
diff_map_fd = bpf_map__fd(skel->maps.diff_readings);
entry->link_id = bpf_link_get_id(link_fd);
entry->diff_map_id = bpf_map_get_id(diff_map_fd);
- err = bpf_map_update_elem(attr_map_fd, &evsel->core.attr, entry, BPF_ANY);
- assert(err == 0);
-
- evsel->bperf_leader_link_fd = bpf_link_get_fd_by_id(entry->link_id);
- assert(evsel->bperf_leader_link_fd >= 0);
-
/*
* save leader_skel for install_pe, which is called within
* following evsel__open_per_cpu call
*/
evsel->leader_skel = skel;
- evsel__open_per_cpu(evsel, all_cpu_map, -1);
+ if (!evsel__open_per_cpu(evsel, all_cpu_map, -1))
+ entry->supported = true;
+
+ err = bpf_map_update_elem(attr_map_fd, &evsel->core.attr, entry, BPF_ANY);
+ assert(err == 0);
+
+ evsel->bperf_leader_link_fd = bpf_link_get_fd_by_id(entry->link_id);
+ assert(evsel->bperf_leader_link_fd >= 0);
out:
bperf_leader_bpf__destroy(skel);
@@ -446,7 +447,7 @@ static int bperf_reload_leader_program(struct evsel *evsel, int attr_map_fd,
static int bperf__load(struct evsel *evsel, struct target *target)
{
- struct perf_event_attr_map_entry entry = {0xffffffff, 0xffffffff};
+ struct perf_event_attr_map_entry entry = {0xffffffff, 0xffffffff, false};
int attr_map_fd, diff_map_fd = -1, err;
enum bperf_filter_type filter_type;
__u32 filter_entry_cnt, i;
@@ -494,6 +495,7 @@ static int bperf__load(struct evsel *evsel, struct target *target)
err = -1;
goto out;
}
+ evsel->supported = entry.supported;
/*
* The bpf_link holds reference to the leader program, and the
* leader program holds reference to the maps. Therefore, if
--
2.34.1
next prev parent reply other threads:[~2024-09-25 14:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-25 13:55 [PATCH -next 0/2] perf stat: a set of small fixes for bperf Tengda Wu
2024-09-25 13:55 ` [PATCH -next 1/2] perf stat: Increase perf_attr_map entries Tengda Wu
2024-09-26 4:16 ` Namhyung Kim
2024-09-27 2:35 ` Tengda Wu
2024-09-27 17:12 ` Namhyung Kim
2024-09-29 0:54 ` Tengda Wu
2024-09-25 13:55 ` Tengda Wu [this message]
2024-10-09 5:20 ` [PATCH -next 0/2] perf stat: a set of small fixes for bperf Namhyung Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240925135523.367957-3-wutengda@huaweicloud.com \
--to=wutengda@huaweicloud.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bpf@vger.kernel.org \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=song@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).