linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
>>

  reply	other threads:[~2022-12-01 11:15 UTC|newest]

Thread overview: 48+ 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 ` [PATCH RFC 1/6] perf vendor events arm64: Add topdown L1 " Jing Zhang
2022-10-31 11:11 ` [PATCH RFC 2/6] perf vendor events arm64: Add TLB " Jing Zhang
2022-10-31 11:11 ` [PATCH RFC 3/6] perf vendor events arm64: Add cache " Jing Zhang
2022-10-31 11:11 ` [PATCH RFC 4/6] perf vendor events arm64: Add branch " 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 ` [PATCH RFC 6/6] perf vendor events arm64: Add instruction mix " Jing Zhang
2022-11-14  7:41 ` [RFC PATCH v2 0/6] Add " Jing Zhang
2022-11-24 17:14   ` [PATCH v3 " 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   ` [PATCH v3 2/6] perf vendor events arm64: Add TLB " Jing Zhang
2022-11-24 17:14   ` [PATCH v3 3/6] perf vendor events arm64: Add cache " Jing Zhang
2022-11-24 17:14   ` [PATCH v3 4/6] perf vendor events arm64: Add branch " Jing Zhang
2022-11-24 17:14   ` [PATCH v3 5/6] perf vendor events arm64: Add PE utilization " Jing Zhang
2022-11-30 18:58     ` Ian Rogers
2022-12-01 11:08       ` Jing Zhang [this message]
2022-12-02 20:05         ` Ian Rogers
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-14  7:41 ` [RFC PATCH v2 1/6] perf vendor events arm64: Add topdown L1 " Jing Zhang
2022-11-14 12:59   ` [External] : " John Garry
2022-11-15  8:43     ` Jing Zhang
2022-11-15 11:19       ` John Garry
2022-11-21  9:53         ` Jing Zhang
2022-11-21 10:22           ` John Garry
2022-11-21 15:17             ` Jing Zhang
2022-11-21 17:55               ` John Garry
2022-11-22  9:24                 ` Jing Zhang
2022-11-22 14:00                 ` James Clark
2022-11-22 15:41                   ` Jing Zhang
2022-11-23 14:26                     ` James Clark
2022-11-24 16:32                       ` Jing Zhang
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 ` [RFC PATCH v2 3/6] perf vendor events arm64: Add cache " Jing Zhang
2022-11-14  8:35   ` Xing Zhengjun
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 ` [RFC PATCH v2 5/6] perf vendor events arm64: Add PE utilization " Jing Zhang
2022-11-14  7:42 ` [RFC PATCH v2 6/6] perf vendor events arm64: Add instruction mix " Jing Zhang
2022-11-16 11:19 ` [PATCH RFC 0/6] Add " James Clark
2022-11-16 15:26   ` Jing Zhang
2022-11-21 11:51     ` James Clark
2022-11-22  7:11       ` Jing Zhang
2022-11-22 11:53         ` James Clark
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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).