linux-kernel - Re: [External] : [RFC PATCH v2 1/6] perf vendor events arm64: Add topdown L1 metrics for neoverse-n2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <75c4f0e6-3f28-a748-e891-7be6016ca28e@oracle.com>
Date:   Mon, 21 Nov 2022 17:55:20 +0000
From:   John Garry <john.g.garry@...cle.com>
To:     Jing Zhang <renyu.zj@...ux.alibaba.com>,
        linux-arm-kernel@...ts.infradead.org,
        linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
        Will Deacon <will@...nel.org>,
        James Clark <james.clark@....com>,
        Mike Leach <mike.leach@...aro.org>,
        Leo Yan <leo.yan@...aro.org>, Ian Rogers <irogers@...gle.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Andrew Kilroy <andrew.kilroy@....com>,
        Shuai Xue <xueshuai@...ux.alibaba.com>,
        Zhuo Song <zhuo.song@...ux.alibaba.com>
Subject: Re: [External] : [RFC PATCH v2 1/6] perf vendor events arm64: Add
 topdown L1 metrics for neoverse-n2

On 21/11/2022 15:17, Jing Zhang wrote:
> I'm sorry that I misunderstood the purpose of putting metric as arch_std_event at first,
> and now it works after the modification over your suggestion.
> 
> But there are also a few questions:
> 
> 1. The value of the slot in the topdownL1 is various in different architectures, for example,
> the slot is 5 on neoverse-n2. If I put topdownL1 metric as arch_std_event, then I need to
> specify the slot to 5 in n2. I can specify slot values in metric like below, but is there any
> other concise way to do this?
> 
> diff --git a/tools/perf/pmu-events/arch/arm64/arm/neoverse-n2/metrics.json b/tools/perf/pmu-events/arch/arm64/arm/neoverse-n2/metrics.json
> index 8ff1dfe..b473baf 100644
> --- a/tools/perf/pmu-events/arch/arm64/arm/neoverse-n2/metrics.json
> +++ b/tools/perf/pmu-events/arch/arm64/arm/neoverse-n2/metrics.json
> @@ -1,4 +1,23 @@
> [
> +       {
> +               "MetricExpr": "5",
> +               "PublicDescription": "A pipeline slot represents the hardware resources needed to process one uOp",
> +               "BriefDescription": "A pipeline slot represents the hardware resources needed to process one uOp",
> +               "MetricName": "slot"

Ehhh....I'm not sure if that is a good idea. Ian or anyone else have an 
opinion on this? It is possible to reuse metrics, so it should work, but...

One problem is that "slot" would show up as a metric, which you would 
not want.

Alternatively I was going to suggest that you can overwrite specific std 
arch event attributes. So for example of frontend_bound, you could have:

+ b/tools/perf/pmu-events/arch/arm64/arm/neoverse-n2/metrics.json
@@ -0,0 +1,30 @@
[
     {
	"ArchStdEvent": "FRONTEND_BOUND",
         "MetricExpr": "(stall_slot_frontend - cpu_cycles) / (5 * 
cpu_cycles)",
     },

> +       }
> +       {
> +               "ArchStdEvent": "FRONTEND_BOUND"
> +       },
> +       {
> +               "ArchStdEvent": "BACKEND_BOUND"
> +       },
> +       {
> +               "ArchStdEvent": "WASTED"
> +       },
> +       {
> +               "ArchStdEvent": "RETIRING"
> +       },
> 
> 
> 2. Should I add the topdownL1 metric to tools/perf/pmu-event/recommended.json,
> or create a new json file to place the general metric?

It would not belong in recommended.json as that is specifically for 
arch-recommended events. It would really just depend on where the value 
comes from, i.e. arm arm or sbsa.

> 
> Looking forward to your reply.