Linux Perf Users
 help / color / mirror / Atom feed
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

  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