From: Ian Rogers <irogers@google.com>
To: Chunxin Zang <spring.cxz@gmail.com>
Cc: peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
namhyung@kernel.org, mark.rutland@arm.com,
alexander.shishkin@linux.intel.com, jolsa@kernel.org,
adrian.hunter@intel.com, yangchen11@lixiang.com,
zhouchunhua@lixiang.com, linux-perf-users@vger.kernel.org,
linux-kernel@vger.kernel.org, zangchunxin@lixiang.com
Subject: Re: [PATCH v2] perf evlist: Fix 'perf record -C xx' failed issue
Date: Tue, 19 Mar 2024 13:33:24 -0700 [thread overview]
Message-ID: <CAP-5=fWD3bmeDoG626gds_R85JrWEAKrd_6hau6LfZXGnD=_NQ@mail.gmail.com> (raw)
In-Reply-To: <20240319091429.2056555-1-spring.cxz@gmail.com>
On Tue, Mar 19, 2024 at 2:14 AM Chunxin Zang <spring.cxz@gmail.com> wrote:
>
> The cpu has 8 performance-cores and 8 efficient-cores on my pc.
> 0-15 are performance-cores
> 16-23 are 8 efficient-cores
>
> When I run "perf record -C xxx", the command fails if xxx all belong to
> performance cores or efficient cores
>
> The results are as follows
>
> # perf record -C 12
> WARNING: A requested CPU in '12' is not supported by PMU 'cpu_atom' (CPUs 16-23) for event 'cycles:P'
> Error:
> The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (cpu_atom/cycles:P/).
> /bin/dmesg | grep -i perf may provide additional information.
>
> # perf record -C 14-17
> WARNING: A requested CPU in '14-17' is not supported by PMU 'cpu_atom' (CPUs 16-23) for event 'cycles:P'
> WARNING: A requested CPU in '14-17' is not supported by PMU 'cpu_core' (CPUs 0-15) for event 'cycles:P'
> ^C[ perf record: Woken up 1 times to write data ]
>
> The reason is that the cpu_map of 'cpu_atom'-evsel is empty, causing
> the sys_perf_event_open() result to fail.
>
> Changes in v2:
> - fix memory leak about 'intersect'
>
> Signed-off-by: Chunxin Zang <spring.cxz@gmail.com>
> Reviewed-by: Chen Yang <yangchen11@lixiang.com>
> ---
> tools/perf/util/evlist.c | 24 +++++++++++++++++-------
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index 55a300a0977b..babbde29341f 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -2499,7 +2499,7 @@ void evlist__check_mem_load_aux(struct evlist *evlist)
> void evlist__warn_user_requested_cpus(struct evlist *evlist, const char *cpu_list)
> {
> struct perf_cpu_map *user_requested_cpus;
> - struct evsel *pos;
> + struct evsel *pos, *tmp;
>
> if (!cpu_list)
> return;
> @@ -2508,18 +2508,28 @@ void evlist__warn_user_requested_cpus(struct evlist *evlist, const char *cpu_lis
> if (!user_requested_cpus)
> return;
>
> - evlist__for_each_entry(evlist, pos) {
> + evlist__for_each_entry_safe(evlist, tmp, pos) {
> struct perf_cpu_map *intersect, *to_test;
> const struct perf_pmu *pmu = evsel__find_pmu(pos);
>
> to_test = pmu && pmu->is_core ? pmu->cpus : cpu_map__online();
Perhaps this would be clearer if we just made sure requested uncore
CPUs were online. Uncore cpu maps are weird, they say the default CPU
but other CPUs are valid. It'd be worth testing the impact of this
change on uncore events.
> intersect = perf_cpu_map__intersect(to_test, user_requested_cpus);
> - if (!perf_cpu_map__equal(intersect, user_requested_cpus)) {
> - char buf[128];
> + if (!intersect) {
> + evlist__remove(evlist, pos);
> + evsel__delete(pos);
> + perf_cpu_map__put(intersect);
evlist__warn_user_requested_cpus seems like a wrong function name if
evsels are being removed. Perhaps something like
evlist__remove_empty_cpu_map_evsels. It seems this change will remove
warnings in cases like:
$ perf record cpu_atom/cycles/ -C 0 ...
I wonder that we need a flag in the evsel to say when an event comes
from wildcard expansion so we only don't warn/remove in that case.
Wrt memory leaks, try compiling with EXTRA_CFLAGS="-fsanitize=address"
which also incorporates leak sanitizer.
Thanks,
Ian
> + continue;
> + }
> +
> + if (!perf_cpu_map__is_subset(user_requested_cpus, intersect)) {
> + char buf_test[128];
> + char buf_intersect[128];
>
> - cpu_map__snprint(to_test, buf, sizeof(buf));
> - pr_warning("WARNING: A requested CPU in '%s' is not supported by PMU '%s' (CPUs %s) for event '%s'\n",
> - cpu_list, pmu ? pmu->name : "cpu", buf, evsel__name(pos));
> + cpu_map__snprint(to_test, buf_test, sizeof(buf_test));
> + cpu_map__snprint(intersect, buf_intersect, sizeof(buf_intersect));
> + pr_warning("WARNING: A requested CPU '%s' in '%s' is not supported by "
> + "PMU '%s' (CPUs %s) for event '%s'\n", buf_intersect, cpu_list,
> + pmu ? pmu->name : "cpu", buf_test, evsel__name(pos));
> }
> perf_cpu_map__put(intersect);
> }
> --
> 2.34.1
>
next prev parent reply other threads:[~2024-03-19 20:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-19 9:14 [PATCH v2] perf evlist: Fix 'perf record -C xx' failed issue Chunxin Zang
2024-03-19 9:43 ` Chunxin Zang
2024-03-19 20:33 ` Ian Rogers [this message]
2024-03-20 12:53 ` Chunxin Zang
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='CAP-5=fWD3bmeDoG626gds_R85JrWEAKrd_6hau6LfZXGnD=_NQ@mail.gmail.com' \
--to=irogers@google.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@kernel.org \
--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=spring.cxz@gmail.com \
--cc=yangchen11@lixiang.com \
--cc=zangchunxin@lixiang.com \
--cc=zhouchunhua@lixiang.com \
/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).