From: sashiko-bot@kernel.org
To: "Besar Wicaksono" <bwicaksono@nvidia.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 8/9] perf evsel: Name a merged uncore counter after all of its PMUs
Date: Fri, 30 Oct 2026 18:09:47 +0000 [thread overview]
Message-ID: <sashiko-outbox-191394@kernel.org> (raw)
In-Reply-To: <20261030174816.1544471-9-bwicaksono@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf evsel: evlist__uniquify_evsel_names() renames unmerged counters
--
commit 570949b12b356d4f0d3d0c5c530601e5cc91533f
Author: Besar Wicaksono <bwicaksono@nvidia.com>
perf evsel: Name a merged uncore counter after all of its PMUs
This commit renames merged uncore counters to reflect all of their underlying
PMU instances, either by stripping a numeric suffix or by replacing differing
numbers with a wildcard when counters are aggregated.
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index c3d7847278106..6720d9dc5af74 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -2767,7 +2767,7 @@ void evlist__uniquify_evsel_names(struct evlist *evlist, const struct perf_stat_
> struct evsel *pos;
>
> evlist__for_each_entry(evlist, pos)
> - evsel__uniquify_counter(pos);
> + evsel__uniquify_counter(pos, config->aggr_mode != AGGR_NONE);
> }
> }
[Severity: Medium]
Can passing config->aggr_mode != AGGR_NONE here cause unmerged uncore counters
to be renamed with the merged PMU name in perf stat --no-aggr, perf record,
and perf top?
In tools/perf/util/config.c, the global stat_config is initialized with
aggr_mode = AGGR_GLOBAL.
In tools/perf/builtin-stat.c, cmd_stat() parses command-line options before
updating stat_config.aggr_mode:
argc = parse_options_subcommand(argc, argv, stat_options, stat_subcommands,
(const char **) stat_usage,
PARSE_OPT_STOP_AT_NON_OPTION);
stat_config.aggr_mode = opt_aggr_mode_to_aggr_mode(&opt_mode);
When -e parses an event group that requires regrouping across PMUs,
__parse_events() in tools/perf/util/parse-events.c calls
evlist__uniquify_evsel_names() while stat_config.aggr_mode is still
AGGR_GLOBAL:
if (ret2 > 0 && warn_if_reordered && !parse_state.wild_card_pmus) {
evlist__uniquify_evsel_names(evlist, &stat_config);
pr_warning("WARNING: events were regrouped to match PMUs\n");
Even when --no-aggr was passed on the command line, this early call sees
config->aggr_mode != AGGR_NONE, renames the first PMU instance to the merged
PMU name, and sets counter->uniquified_name = true in
evsel__uniquify_counter():
/* The evsel was already uniquified. */
if (counter->uniquified_name)
return;
/* Avoid checking to uniquify twice. */
counter->uniquified_name = true;
When evlist__print_counters() later calls evlist__uniquify_evsel_names() with
AGGR_NONE, the first PMU instance returns early and keeps the merged wildcard
or suffix-stripped name while the remaining instances are given their
individual PMU names.
Similarly, __cmd_record() in tools/perf/builtin-record.c and __cmd_top() in
tools/perf/builtin-top.c call evlist__uniquify_evsel_names() with the global
&stat_config:
/*
* Use global stat_config that is zero meaning aggr_mode is AGGR_NONE
* and hybrid_merge is false.
*/
evlist__uniquify_evsel_names(rec->evlist, &stat_config);
Because stat_config.aggr_mode is actually AGGR_GLOBAL rather than AGGR_NONE,
wouldn't perf record and perf top also rename the first uncore PMU instance as
if its counts were merged?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261030174816.1544471-1-bwicaksono@nvidia.com?part=8
next prev parent reply other threads:[~2026-10-30 18:09 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 17:48 [PATCH v2 0/9] perf: Add NVIDIA Tegra410 uncore PMU events and metrics Besar Wicaksono
2026-10-30 17:48 ` [PATCH v2 1/9] perf jevents: Add support for NVIDIA Tegra410 UCF PMU aliasing Besar Wicaksono
2026-10-30 18:01 ` sashiko-bot
2026-10-30 17:48 ` [PATCH v2 2/9] perf jevents: Add support for NVIDIA Tegra410 PCIE " Besar Wicaksono
2026-10-30 17:58 ` sashiko-bot
2026-10-30 17:48 ` [PATCH v2 3/9] perf jevents: Add support for NVIDIA Tegra410 PCIE-TGT " Besar Wicaksono
2026-10-30 17:56 ` sashiko-bot
2026-10-30 17:48 ` [PATCH v2 4/9] perf jevents: Add support for NVIDIA Tegra410 CPU Memory Latency " Besar Wicaksono
2026-10-30 17:55 ` sashiko-bot
2026-10-30 17:48 ` [PATCH v2 5/9] perf jevents: Add support for NVIDIA Tegra410 C2C " Besar Wicaksono
2026-10-30 17:57 ` sashiko-bot
2026-10-30 17:48 ` [PATCH v2 6/9] perf stat: Check merged PMU instance's cpumasks when skipping zero counts Besar Wicaksono
2026-10-30 17:58 ` sashiko-bot
2026-10-30 17:48 ` [PATCH v2 7/9] perf pmu: Merge PMU instances that match the same comma-separated json Unit Besar Wicaksono
2026-10-30 17:58 ` sashiko-bot
2026-10-30 17:48 ` [PATCH v2 8/9] perf evsel: Name a merged uncore counter after all of its PMUs Besar Wicaksono
2026-10-30 18:09 ` sashiko-bot [this message]
2026-10-30 17:48 ` [PATCH v2 9/9] perf Documentation: Describe PMU names numbered in more than one place Besar Wicaksono
2026-10-30 17:58 ` sashiko-bot
2026-10-30 18:07 ` [PATCH v2 0/9] perf: Add NVIDIA Tegra410 uncore PMU events and metrics Ian Rogers
2026-10-30 22:18 ` Besar Wicaksono
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=sashiko-outbox-191394@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bwicaksono@nvidia.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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