The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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.


  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