From: "Falcon, Thomas" <thomas.falcon@intel.com>
To: "namhyung@kernel.org" <namhyung@kernel.org>,
"james.clark@linaro.org" <james.clark@linaro.org>,
"linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>,
"irogers@google.com" <irogers@google.com>
Cc: "alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
"yangyicong@hisilicon.com" <yangyicong@hisilicon.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"acme@kernel.org" <acme@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"kan.liang@linux.intel.com" <kan.liang@linux.intel.com>,
"Hunter, Adrian" <adrian.hunter@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jolsa@kernel.org" <jolsa@kernel.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>
Subject: Re: [PATCH v2] perf stat: Fix non-uniquified hybrid legacy events
Date: Mon, 3 Mar 2025 17:20:15 +0000 [thread overview]
Message-ID: <092a915aa9bc67b007ffd3ff6f53b0716426c532.camel@intel.com> (raw)
In-Reply-To: <20250226145526.632380-1-james.clark@linaro.org>
On Wed, 2025-02-26 at 14:55 +0000, James Clark wrote:
> Legacy hybrid events have attr.type == PERF_TYPE_HARDWARE, so they
> look
> like plain legacy events if we only look at attr.type. But legacy
> events
> should still be uniquified if they were opened on a non-legacy PMU.
> Fix
> it by checking if the evsel is hybrid and forcing needs_uniquify
> before looking at the attr.type.
>
> This restores PMU names on hybrid systems and also changes "perf stat
> metrics (shadow stat) test" from a FAIL back to a SKIP (on hybrid).
> The
> test was gated on "cycles" appearing alone which doesn't happen on
> here.
>
> Before:
> $ perf stat -- true
> ...
> <not counted> instructions:u
> (0.00%)
> 162,536 instructions:u # 0.58 insn per
> cycle
> ...
>
> After:
> $ perf stat -- true
> ...
> <not counted> cpu_atom/instructions/u
> (0.00%)
> 162,541 cpu_core/instructions/u # 0.62 insn per
> cycle
> ...
>
> Fixes: 357b965deba9 ("perf stat: Changes to event name
> uniquification")
> Suggested-by: Ian Rogers <irogers@google.com>
> Signed-off-by: James Clark <james.clark@linaro.org>
Works for me on a i9-12900. Thanks!
Tested-by: Thomas Falcon <thomas.falcon@intel.com>
> ---
>
> Changes since V1:
> * Move the existing evsel__is_hybrid() test earlier instead of
> looking
> at the PMU of the evsel. Looking at the PMU creates a dependency
> that
> the PMU is assigned which may prevent refactors in the future.
>
> tools/perf/util/stat-display.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-
> display.c
> index e65c7e9f15d1..e852ac0d9847 100644
> --- a/tools/perf/util/stat-display.c
> +++ b/tools/perf/util/stat-display.c
> @@ -1688,6 +1688,12 @@ static void evsel__set_needs_uniquify(struct
> evsel *counter, const struct perf_s
> return;
> }
>
> + if (!config->hybrid_merge && evsel__is_hybrid(counter)) {
> + /* Unique hybrid counters necessary. */
> + counter->needs_uniquify = true;
> + return;
> + }
> +
> if (counter->core.attr.type < PERF_TYPE_MAX && counter-
> >core.attr.type != PERF_TYPE_RAW) {
> /* Legacy event, don't uniquify. */
> return;
> @@ -1705,12 +1711,6 @@ static void evsel__set_needs_uniquify(struct
> evsel *counter, const struct perf_s
> return;
> }
>
> - if (!config->hybrid_merge && evsel__is_hybrid(counter)) {
> - /* Unique hybrid counters necessary. */
> - counter->needs_uniquify = true;
> - return;
> - }
> -
> /*
> * Do other non-merged events in the evlist have the same
> name? If so
> * uniquify is necessary.
next prev parent reply other threads:[~2025-03-03 17:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-26 14:55 [PATCH v2] perf stat: Fix non-uniquified hybrid legacy events James Clark
2025-03-03 17:20 ` Falcon, Thomas [this message]
2025-03-04 18:40 ` 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=092a915aa9bc67b007ffd3ff6f53b0716426c532.camel@intel.com \
--to=thomas.falcon@intel.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--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=yangyicong@hisilicon.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