mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Clark <james.clark@arm.com>
To: John Garry <john.g.garry@oracle.com>,
	linux-perf-users@vger.kernel.org, irogers@google.com,
	renyu.zj@linux.alibaba.com
Cc: Will Deacon <will@kernel.org>, Mike Leach <mike.leach@linaro.org>,
	Leo Yan <leo.yan@linaro.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Kajol Jain <kjain@linux.ibm.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Nick Forrington <nick.forrington@arm.com>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Rob Herring <robh@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org
Subject: Re: [PATCH v4 5/6] perf vendor events arm64: Update stall_slot workaround for N2 r0p3
Date: Wed, 9 Aug 2023 14:06:30 +0100	[thread overview]
Message-ID: <a4b93320-cf5d-9622-77fe-f51e1ec7f75b@arm.com> (raw)
In-Reply-To: <6b3d8f28-9a38-d544-e396-706022f2e5f5@oracle.com>



On 08/08/2023 11:18, John Garry wrote:
> On 07/08/2023 15:20, James Clark wrote:
> 
> Hi James,
> 
> Thanks for the effort in doing this.
> 
>> N2 r0p3 doesn't require the workaround [1], so gating on (#slots - 5) no
>> longer works because all N2s have 5 slots. Add a new expression builtin
>> that identifies the need for the workaround correctly.
>>
>> [1]:
>> https://urldefense.com/v3/__https://gitlab.arm.com/telemetry-solution/telemetry-solution/-/blob/main/data/pmu/cpu/neoverse/neoverse-n2-r0p3.json__;!!ACWV5N9M2RV99hQ!Nx1xgWXXS9GBasNpOKQXHWKe8VwpRB0h8lAfOmwUmkkOQTjFqn2NswO8ti8vTcblUfAYN9NAtxqAh-sf0TEOvQ$
>> Signed-off-by: James Clark <james.clark@arm.com>
>> ---
>>   tools/perf/arch/arm64/util/pmu.c              | 21 +++++++++++++++++++
>>   .../arm64/arm/neoverse-n2-v2/metrics.json     |  8 +++----
>>   tools/perf/util/expr.c                        |  4 ++++
>>   tools/perf/util/pmu.c                         |  6 ++++++
>>   tools/perf/util/pmu.h                         |  1 +
>>   5 files changed, 36 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/perf/arch/arm64/util/pmu.c
>> b/tools/perf/arch/arm64/util/pmu.c
>> index 561de0cb6b95..30e2385a83cf 100644
>> --- a/tools/perf/arch/arm64/util/pmu.c
>> +++ b/tools/perf/arch/arm64/util/pmu.c
>> @@ -2,6 +2,7 @@
>>     #include <internal/cpumap.h>
>>   #include "../../../util/cpumap.h"
>> +#include "../../../util/header.h"
>>   #include "../../../util/pmu.h"
>>   #include "../../../util/pmus.h"
>>   #include <api/fs/fs.h>
>> @@ -62,3 +63,23 @@ double perf_pmu__cpu_slots_per_cycle(void)
>>         return slots ? (double)slots : NAN;
>>   }
>> +
>> +double perf_pmu__no_stall_errata(void)
> 
> While I like the approach of encoding the per-CPU support in the metric
> expression, I find that literal "no stall errata" is vague and could
> apply to any "stall errata" for any SoC for any architecture.
> 
> If we were going to do it this way, then we would need a more specific
> name, like perf_pmu__no_stall_errata_arm64_errata123456(), but that
> should not be in the core perf code.
> 
> Could we instead add a function to check cpuid and have something like
> this in the JSON:
> 
> "MetricExpr": "(op_retired / op_spec) * (1 - (stall_slot if
> (cpuid_less_than(410fd493)) else (stall_slot - cpu_cycles)) / (#slots *
> cpu_cycles))"
> 
> I'm currently figuring out how cpuid_less_than() would be implemented
> (I'm no great python wrangler), but it would be along the lines of what
> Ian added for "has_event" in
> https://lore.kernel.org/linux-perf-users/20230623151016.4193660-1-irogers@google.com/
> 
> Thanks,
> John

Yeah it looks like it could be done that way. Also, the way I added it,
it doesn't have access to the PMU type, it just does a generic
pmu__find_core_pmu() so won't work very well for heterogeneous systems.

If we're going to do a deeper modification of the expression parser like
with has_event() it might be possible to pass in the actual CPU ID that
the metric is running on which would be better.

I'll have a look.

James


  reply	other threads:[~2023-08-09 13:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-07 14:20 [PATCH v4 0/6] perf vendor events arm64: Update N2 and V2 metrics and events using Arm telemetry repo James Clark
2023-08-07 14:20 ` [PATCH v4 1/6] perf: cs-etm: Don't duplicate FIELD_GET() James Clark
2023-08-08  7:36   ` John Garry
2023-08-07 14:20 ` [PATCH v4 2/6] perf arm64: Allow version comparisons of CPU IDs James Clark
2023-08-07 14:20 ` [PATCH v4 3/6] perf test: Add a test for the new Arm CPU ID comparison behavior James Clark
2023-08-07 14:20 ` [PATCH v4 4/6] perf vendor events arm64: Update scale units and descriptions of common topdown metrics James Clark
2023-08-08  8:46   ` John Garry
2023-08-09 12:59     ` James Clark
2023-08-07 14:20 ` [PATCH v4 5/6] perf vendor events arm64: Update stall_slot workaround for N2 r0p3 James Clark
2023-08-08 10:18   ` John Garry
2023-08-09 13:06     ` James Clark [this message]
2023-08-09 13:54       ` John Garry
2023-08-09 15:14         ` James Clark
2023-08-07 14:20 ` [PATCH v4 6/6] perf vendor events arm64: Update N2 and V2 metrics and events using Arm telemetry repo James Clark

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=a4b93320-cf5d-9622-77fe-f51e1ec7f75b@arm.com \
    --to=james.clark@arm.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=coresight@lists.linaro.org \
    --cc=eddyz87@gmail.com \
    --cc=irogers@google.com \
    --cc=john.g.garry@oracle.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=kjain@linux.ibm.com \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mike.leach@linaro.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=nick.forrington@arm.com \
    --cc=peterz@infradead.org \
    --cc=renyu.zj@linux.alibaba.com \
    --cc=robh@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    /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

all inboxes | Powered by JetHome®