From: Jing Zhang <renyu.zj@linux.alibaba.com>
To: Ian Rogers <irogers@google.com>
Cc: John Garry <john.g.garry@oracle.com>,
Xing Zhengjun <zhengjun.xing@linux.intel.com>,
Will Deacon <will@kernel.org>, James Clark <james.clark@arm.com>,
Mike Leach <mike.leach@linaro.org>, Leo Yan <leo.yan@linaro.org>,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.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>,
Andrew Kilroy <andrew.kilroy@arm.com>,
Shuai Xue <xueshuai@linux.alibaba.com>,
Zhuo Song <zhuo.song@linux.alibaba.com>
Subject: Re: [PATCH v3 5/6] perf vendor events arm64: Add PE utilization metrics for neoverse-n2
Date: Thu, 1 Dec 2022 19:08:33 +0800 [thread overview]
Message-ID: <1a7fc9da-2589-1835-716f-d52027f0ecda@linux.alibaba.com> (raw)
In-Reply-To: <CAP-5=fV0WSTK=MT6K2nqsqYT6xCTg7Pv_rXahHFeRhV0ZHCiEQ@mail.gmail.com>
在 2022/12/1 上午2:58, Ian Rogers 写道:
> On Thu, Nov 24, 2022 at 9:15 AM Jing Zhang <renyu.zj@linux.alibaba.com> wrote:
>>
>> Add PE utilization related metrics.
>>
>> Signed-off-by: Jing Zhang <renyu.zj@linux.alibaba.com>
>> ---
>> .../arch/arm64/arm/neoverse-n2/metrics.json | 45 ++++++++++++++++++++++
>> 1 file changed, 45 insertions(+)
>>
>> 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 23c7d62..7b54819 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
>> @@ -189,5 +189,50 @@
>> "MetricGroup": "Branch",
>> "MetricName": "branch_miss_pred_rate",
>> "ScaleUnit": "100%"
>> + },
>> + {
>> + "MetricExpr": "instructions / CPU_CYCLES",
>> + "PublicDescription": "The average number of instructions executed for each cycle.",
>> + "BriefDescription": "Instructions per cycle",
>> + "MetricGroup": "PEutilization",
>> + "MetricName": "ipc"
>> + },
>
> A related useful metric is percentage of peak, so if the peak IPC is 8
> (usually a constant related to the number of functional units) then
> you can just compute the ratio of IPC with this.
>
Glad to discuss these with you.
The peak ipc value of neoverse-n2 is 5. Maybe I should add an ipc_rate metric?
>> + {
>> + "MetricExpr": "INST_RETIRED / CPU_CYCLES",
>> + "PublicDescription": "Architecturally executed Instructions Per Cycle (IPC)",
>> + "BriefDescription": "Architecturally executed Instructions Per Cycle (IPC)",
>
>
> The duplicated descriptions are unnecessary. Drop the public one for
> consistency with what we do for Intel:
> https://github.com/intel/perfmon/blob/main/scripts/create_perf_json.py#L299
>
Sounds good, will do.
>> + "MetricGroup": "PEutilization",
>> + "MetricName": "retired_ipc"
>> + },
>> + {
>> + "MetricExpr": "INST_SPEC / CPU_CYCLES",
>> + "PublicDescription": "Speculatively executed Instructions Per Cycle (IPC)",
>> + "BriefDescription": "Speculatively executed Instructions Per Cycle (IPC)",
>> + "MetricGroup": "PEutilization",
>> + "MetricName": "spec_ipc"
>> + },
>> + {
>> + "MetricExpr": "OP_RETIRED / OP_SPEC",
>> + "PublicDescription": "Fraction of operations retired",
>> + "BriefDescription": "Fraction of operations retired",
>
> Would instructions be clearer than operations here?
>
operation and instruction are different. OP_RETIRED counts any operation (not instruction)
that has been architecturally executed, For example, speculatively executed operations that
have been abandoned for a branch mispredict will not be counted. So I think operation might
be more accurate.
>> + "MetricGroup": "PEutilization",
>> + "MetricName": "retired_rate",
>> + "ScaleUnit": "100%"
>> + },
>> + {
>> + "MetricExpr": "1 - OP_RETIRED / OP_SPEC",
>
> Should OP_RETIRED be greater than OP_SPEC? In which case won't this
> metric be negative?
>
OP_RETIRED will not be greater than OP_SPEC. OP_SPEC counts any operation that has been
speculatively executed. OP_SPEC is a superset of the OP_RETIRED event. There is a
description about OP_SPEC and OP_RETIRED in this neoverse-n2 document.
Link: https://documentation-service.arm.com/static/62cfe21e31ea212bb6627393?token=
>> + "PublicDescription": "Fraction of operations wasted",
>> + "BriefDescription": "Fraction of operations wasted",
>> + "MetricGroup": "PEutilization",
>> + "MetricName": "wasted_rate",
>> + "ScaleUnit": "100%"
>> + },
>> + {
>> + "MetricExpr": "OP_RETIRED / OP_SPEC * (1 - (STALL_SLOT - CPU_CYCLES) / (CPU_CYCLES * 5))",
>> + "PublicDescription": "Utilization of CPU",
>> + "BriefDescription": "Utilization of CPU",
>
> Some more detail in the description would be useful.
>
Ok, I'll describe it in more detail. CPU_utilization reflects the truly effective ratio of operation
executed by the CPU, which means that misprediction and stall are not included. Note that stall_slot
minus cpu_cycles is a correction to the stall_slot error count.
>> + "MetricGroup": "PEutilization",
>> + "MetricName": "cpu_utilization",
>> + "ScaleUnit": "100%"
>> }
>> ]
>> --
>> 1.8.3.1
>>
WARNING: multiple messages have this Message-ID (diff)
From: Jing Zhang <renyu.zj@linux.alibaba.com>
To: Ian Rogers <irogers@google.com>
Cc: John Garry <john.g.garry@oracle.com>,
Xing Zhengjun <zhengjun.xing@linux.intel.com>,
Will Deacon <will@kernel.org>, James Clark <james.clark@arm.com>,
Mike Leach <mike.leach@linaro.org>, Leo Yan <leo.yan@linaro.org>,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.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>,
Andrew Kilroy <andrew.kilroy@arm.com>,
Shuai Xue <xueshuai@linux.alibaba.com>,
Zhuo Song <zhuo.song@linux.alibaba.com>
Subject: Re: [PATCH v3 5/6] perf vendor events arm64: Add PE utilization metrics for neoverse-n2
Date: Thu, 1 Dec 2022 19:08:33 +0800 [thread overview]
Message-ID: <1a7fc9da-2589-1835-716f-d52027f0ecda@linux.alibaba.com> (raw)
In-Reply-To: <CAP-5=fV0WSTK=MT6K2nqsqYT6xCTg7Pv_rXahHFeRhV0ZHCiEQ@mail.gmail.com>
在 2022/12/1 上午2:58, Ian Rogers 写道:
> On Thu, Nov 24, 2022 at 9:15 AM Jing Zhang <renyu.zj@linux.alibaba.com> wrote:
>>
>> Add PE utilization related metrics.
>>
>> Signed-off-by: Jing Zhang <renyu.zj@linux.alibaba.com>
>> ---
>> .../arch/arm64/arm/neoverse-n2/metrics.json | 45 ++++++++++++++++++++++
>> 1 file changed, 45 insertions(+)
>>
>> 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 23c7d62..7b54819 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
>> @@ -189,5 +189,50 @@
>> "MetricGroup": "Branch",
>> "MetricName": "branch_miss_pred_rate",
>> "ScaleUnit": "100%"
>> + },
>> + {
>> + "MetricExpr": "instructions / CPU_CYCLES",
>> + "PublicDescription": "The average number of instructions executed for each cycle.",
>> + "BriefDescription": "Instructions per cycle",
>> + "MetricGroup": "PEutilization",
>> + "MetricName": "ipc"
>> + },
>
> A related useful metric is percentage of peak, so if the peak IPC is 8
> (usually a constant related to the number of functional units) then
> you can just compute the ratio of IPC with this.
>
Glad to discuss these with you.
The peak ipc value of neoverse-n2 is 5. Maybe I should add an ipc_rate metric?
>> + {
>> + "MetricExpr": "INST_RETIRED / CPU_CYCLES",
>> + "PublicDescription": "Architecturally executed Instructions Per Cycle (IPC)",
>> + "BriefDescription": "Architecturally executed Instructions Per Cycle (IPC)",
>
>
> The duplicated descriptions are unnecessary. Drop the public one for
> consistency with what we do for Intel:
> https://github.com/intel/perfmon/blob/main/scripts/create_perf_json.py#L299
>
Sounds good, will do.
>> + "MetricGroup": "PEutilization",
>> + "MetricName": "retired_ipc"
>> + },
>> + {
>> + "MetricExpr": "INST_SPEC / CPU_CYCLES",
>> + "PublicDescription": "Speculatively executed Instructions Per Cycle (IPC)",
>> + "BriefDescription": "Speculatively executed Instructions Per Cycle (IPC)",
>> + "MetricGroup": "PEutilization",
>> + "MetricName": "spec_ipc"
>> + },
>> + {
>> + "MetricExpr": "OP_RETIRED / OP_SPEC",
>> + "PublicDescription": "Fraction of operations retired",
>> + "BriefDescription": "Fraction of operations retired",
>
> Would instructions be clearer than operations here?
>
operation and instruction are different. OP_RETIRED counts any operation (not instruction)
that has been architecturally executed, For example, speculatively executed operations that
have been abandoned for a branch mispredict will not be counted. So I think operation might
be more accurate.
>> + "MetricGroup": "PEutilization",
>> + "MetricName": "retired_rate",
>> + "ScaleUnit": "100%"
>> + },
>> + {
>> + "MetricExpr": "1 - OP_RETIRED / OP_SPEC",
>
> Should OP_RETIRED be greater than OP_SPEC? In which case won't this
> metric be negative?
>
OP_RETIRED will not be greater than OP_SPEC. OP_SPEC counts any operation that has been
speculatively executed. OP_SPEC is a superset of the OP_RETIRED event. There is a
description about OP_SPEC and OP_RETIRED in this neoverse-n2 document.
Link: https://documentation-service.arm.com/static/62cfe21e31ea212bb6627393?token=
>> + "PublicDescription": "Fraction of operations wasted",
>> + "BriefDescription": "Fraction of operations wasted",
>> + "MetricGroup": "PEutilization",
>> + "MetricName": "wasted_rate",
>> + "ScaleUnit": "100%"
>> + },
>> + {
>> + "MetricExpr": "OP_RETIRED / OP_SPEC * (1 - (STALL_SLOT - CPU_CYCLES) / (CPU_CYCLES * 5))",
>> + "PublicDescription": "Utilization of CPU",
>> + "BriefDescription": "Utilization of CPU",
>
> Some more detail in the description would be useful.
>
Ok, I'll describe it in more detail. CPU_utilization reflects the truly effective ratio of operation
executed by the CPU, which means that misprediction and stall are not included. Note that stall_slot
minus cpu_cycles is a correction to the stall_slot error count.
>> + "MetricGroup": "PEutilization",
>> + "MetricName": "cpu_utilization",
>> + "ScaleUnit": "100%"
>> }
>> ]
>> --
>> 1.8.3.1
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-12-01 11:15 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-31 11:11 [PATCH RFC 0/6] Add metrics for neoverse-n2 Jing Zhang
2022-10-31 11:11 ` Jing Zhang
2022-10-31 11:11 ` [PATCH RFC 1/6] perf vendor events arm64: Add topdown L1 " Jing Zhang
2022-10-31 11:11 ` Jing Zhang
2022-10-31 11:11 ` [PATCH RFC 2/6] perf vendor events arm64: Add TLB " Jing Zhang
2022-10-31 11:11 ` Jing Zhang
2022-10-31 11:11 ` [PATCH RFC 3/6] perf vendor events arm64: Add cache " Jing Zhang
2022-10-31 11:11 ` Jing Zhang
2022-10-31 11:11 ` [PATCH RFC 4/6] perf vendor events arm64: Add branch " Jing Zhang
2022-10-31 11:11 ` Jing Zhang
2022-10-31 11:11 ` [PATCH RFC 5/6] perf vendor events arm64: Add PE utilization " Jing Zhang
2022-10-31 11:11 ` Jing Zhang
2022-10-31 11:11 ` [PATCH RFC 6/6] perf vendor events arm64: Add instruction mix " Jing Zhang
2022-10-31 11:11 ` Jing Zhang
2022-11-14 7:41 ` [RFC PATCH v2 0/6] Add " Jing Zhang
2022-11-14 7:41 ` Jing Zhang
2022-11-24 17:14 ` [PATCH v3 " Jing Zhang
2022-11-24 17:14 ` Jing Zhang
2022-11-24 17:14 ` [PATCH v3 1/6] perf vendor events arm64: Add topdown L1 " Jing Zhang
2022-11-24 17:14 ` Jing Zhang
2022-11-24 17:14 ` [PATCH v3 2/6] perf vendor events arm64: Add TLB " Jing Zhang
2022-11-24 17:14 ` Jing Zhang
2022-11-24 17:14 ` [PATCH v3 3/6] perf vendor events arm64: Add cache " Jing Zhang
2022-11-24 17:14 ` Jing Zhang
2022-11-24 17:14 ` [PATCH v3 4/6] perf vendor events arm64: Add branch " Jing Zhang
2022-11-24 17:14 ` Jing Zhang
2022-11-24 17:14 ` [PATCH v3 5/6] perf vendor events arm64: Add PE utilization " Jing Zhang
2022-11-24 17:14 ` Jing Zhang
2022-11-30 18:58 ` Ian Rogers
2022-11-30 18:58 ` Ian Rogers
2022-12-01 11:08 ` Jing Zhang [this message]
2022-12-01 11:08 ` Jing Zhang
2022-12-02 20:05 ` Ian Rogers
2022-12-02 20:05 ` Ian Rogers
2022-12-04 7:10 ` Jing Zhang
2022-12-04 7:10 ` Jing Zhang
2022-11-24 17:14 ` [PATCH v3 6/6] perf vendor events arm64: Add instruction mix " Jing Zhang
2022-11-24 17:14 ` Jing Zhang
2022-11-14 7:41 ` [RFC PATCH v2 1/6] perf vendor events arm64: Add topdown L1 " Jing Zhang
2022-11-14 7:41 ` Jing Zhang
2022-11-14 12:59 ` [External] : " John Garry
2022-11-14 12:59 ` John Garry
2022-11-15 8:43 ` Jing Zhang
2022-11-15 8:43 ` Jing Zhang
2022-11-15 11:19 ` John Garry
2022-11-15 11:19 ` John Garry
2022-11-21 9:53 ` Jing Zhang
2022-11-21 9:53 ` Jing Zhang
2022-11-21 10:22 ` John Garry
2022-11-21 10:22 ` John Garry
2022-11-21 15:17 ` Jing Zhang
2022-11-21 15:17 ` Jing Zhang
2022-11-21 17:55 ` John Garry
2022-11-21 17:55 ` John Garry
2022-11-22 9:24 ` Jing Zhang
2022-11-22 9:24 ` Jing Zhang
2022-11-22 14:00 ` James Clark
2022-11-22 14:00 ` James Clark
2022-11-22 15:41 ` Jing Zhang
2022-11-22 15:41 ` Jing Zhang
2022-11-23 14:26 ` James Clark
2022-11-23 14:26 ` James Clark
2022-11-24 16:32 ` Jing Zhang
2022-11-24 16:32 ` Jing Zhang
2022-11-24 16:51 ` James Clark
2022-11-24 16:51 ` James Clark
2022-11-14 7:41 ` [RFC PATCH v2 2/6] perf vendor events arm64: Add TLB " Jing Zhang
2022-11-14 7:41 ` Jing Zhang
2022-11-14 7:41 ` [RFC PATCH v2 3/6] perf vendor events arm64: Add cache " Jing Zhang
2022-11-14 7:41 ` Jing Zhang
2022-11-14 8:35 ` Xing Zhengjun
2022-11-14 8:35 ` Xing Zhengjun
2022-11-15 6:28 ` Jing Zhang
2022-11-15 6:28 ` Jing Zhang
2022-11-14 7:41 ` [RFC PATCH v2 4/6] perf vendor events arm64: Add branch " Jing Zhang
2022-11-14 7:41 ` Jing Zhang
2022-11-14 7:41 ` [RFC PATCH v2 5/6] perf vendor events arm64: Add PE utilization " Jing Zhang
2022-11-14 7:41 ` Jing Zhang
2022-11-14 7:42 ` [RFC PATCH v2 6/6] perf vendor events arm64: Add instruction mix " Jing Zhang
2022-11-14 7:42 ` Jing Zhang
2022-11-16 11:19 ` [PATCH RFC 0/6] Add " James Clark
2022-11-16 11:19 ` James Clark
2022-11-16 15:26 ` Jing Zhang
2022-11-16 15:26 ` Jing Zhang
2022-11-21 11:51 ` James Clark
2022-11-21 11:51 ` James Clark
2022-11-22 7:11 ` Jing Zhang
2022-11-22 7:11 ` Jing Zhang
2022-11-22 11:53 ` James Clark
2022-11-22 11:53 ` James Clark
2022-11-19 3:30 ` Jing Zhang
2022-11-19 3:30 ` Jing Zhang
[not found] ` <CAP-5=fW+Z_Tc3BfK1bRKUeKWfxtPfoZXL9D2BhcU1SzNOruSsg@mail.gmail.com>
2022-11-20 3:49 ` Jing Zhang
2022-11-20 3:49 ` Jing Zhang
2022-11-21 11:55 ` James Clark
2022-11-21 11:55 ` 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=1a7fc9da-2589-1835-716f-d52027f0ecda@linux.alibaba.com \
--to=renyu.zj@linux.alibaba.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=andrew.kilroy@arm.com \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=john.g.garry@oracle.com \
--cc=jolsa@kernel.org \
--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=peterz@infradead.org \
--cc=will@kernel.org \
--cc=xueshuai@linux.alibaba.com \
--cc=zhengjun.xing@linux.intel.com \
--cc=zhuo.song@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.