Date:   Tue, 13 Dec 2022 15:15:57 +0530
From:   Sandipan Das <sandipan.das@....com>
To:     Ian Rogers <irogers@...gle.com>
Cc:     linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
        acme@...nel.org, peterz@...radead.org, mingo@...hat.com,
        mark.rutland@....com, alexander.shishkin@...ux.intel.com,
        jolsa@...nel.org, namhyung@...nel.org, eranian@...gle.com,
        jhladky@...hat.com, ravi.bangoria@....com, ananth.narayan@....com
Subject: Re: [PATCH 4/4] perf vendor events amd: Add Zen 4 metrics

On 12/7/2022 11:14 PM, Ian Rogers wrote:
> On Tue, Dec 6, 2022 at 9:32 PM Sandipan Das <sandipan.das@....com> wrote:
>>
>> Add metrics taken from Section 2.1.15.2 "Performance Measurement" in
>> the Processor Programming Reference (PPR) for AMD Family 19h Model 11h
>> Revision B1 processors.
>>
>> The recommended metrics are sourced from Table 27 "Guidance for Common
>> Performance Statistics with Complex Event Selects".
>>
>> The pipeline utilization metrics are sourced from Table 28 "Guidance
>> for Pipeline Utilization Analysis Statistics". These are new to Zen 4
>> processors and useful for finding performance bottlenecks by analyzing
>> activity at different stages of the pipeline. Metric groups have been
>> added for Level 1 and Level 2 analysis.
>>
>> Signed-off-by: Sandipan Das <sandipan.das@....com>
>> ---
>>  .../pmu-events/arch/x86/amdzen4/pipeline.json |  98 +++++
>>  .../arch/x86/amdzen4/recommended.json         | 334 ++++++++++++++++++
>>  2 files changed, 432 insertions(+)
>>  create mode 100644 tools/perf/pmu-events/arch/x86/amdzen4/pipeline.json
>>  create mode 100644 tools/perf/pmu-events/arch/x86/amdzen4/recommended.json
>>
>> diff --git a/tools/perf/pmu-events/arch/x86/amdzen4/pipeline.json b/tools/perf/pmu-events/arch/x86/amdzen4/pipeline.json
>> new file mode 100644
>> index 000000000000..23d1f35d0903
>> --- /dev/null
>> +++ b/tools/perf/pmu-events/arch/x86/amdzen4/pipeline.json
>> @@ -0,0 +1,98 @@
>> +[
>> +  {
>> +    "MetricName": "total_dispatch_slots",
>> +    "BriefDescription": "Total dispatch slots (upto 6 instructions can be dispatched in each cycle).",
>> +    "MetricExpr": "6 * ls_not_halted_cyc"
>> +  },
>> +  {
>> +    "MetricName": "frontend_bound",
>> +    "BriefDescription": "Fraction of dispatch slots that remained unused because the frontend did not supply enough instructions/ops.",
>> +    "MetricExpr": "d_ratio(de_no_dispatch_per_slot.no_ops_from_frontend, total_dispatch_slots)",
>> +    "MetricGroup": "pipeline_utilization_level1",
> 
> It might be useful here to add the metric group TopdownL1, there was a
> proposal to use this with --topdown when topdown events aren't
> present:
> https://lore.kernel.org/linux-perf-users/20211214184240.24215-2-andrew.kilroy@arm.com/
> We also describe topdown analysis using metrics starting from this metric group:
> https://perf.wiki.kernel.org/index.php/Top-Down_Analysis
> 

Thanks for the suggestion.

After looking at Section 3 "Top-Down Analysis" from the original paper [1]
on top-down analysis, my understanding is that a specific categorization of
metrics is expected at each level. E.g. for Level 1 analysis, the metrics
are "Retiring", "Bad Speculation", "Frontend Bound" and "Backend Bound".
For Zen 4, an additional metric here is "SMT Contention". So the pipeline
utilization data has information that overlaps but is also different at the
same time. Hence, the classification may not strictly adhere to the current
notion of top-down.

[1] "A Top-Down method for performance analysis and counters architecture"
    https://ieeexplore.ieee.org/document/6844459

>> +    "ScaleUnit": "100%"
>> +  },
>> +  {
>> +    "MetricName": "bad_speculation",
>> +    "BriefDescription": "Fraction of dispatched ops that did not retire.",
>> +    "MetricExpr": "d_ratio(de_src_op_disp.all - ex_ret_ops, total_dispatch_slots)",
>> +    "MetricGroup": "pipeline_utilization_level1",
>> +    "ScaleUnit": "100%"
>> +  },
>> +  {
>> +    "MetricName": "backend_bound",
>> +    "BriefDescription": "Fraction of dispatch slots that remained unused because of backend stalls.",
>> +    "MetricExpr": "d_ratio(de_no_dispatch_per_slot.backend_stalls, total_dispatch_slots)",
>> +    "MetricGroup": "pipeline_utilization_level1",
>> +    "ScaleUnit": "100%"
>> +  },
>> +  {
>> +    "MetricName": "smt_contention",
>> +    "BriefDescription": "Fraction of dispatch slots that remained unused because the other thread was selected.",
>> +    "MetricExpr": "d_ratio(de_no_dispatch_per_slot.smt_contention, total_dispatch_slots)",
>> +    "MetricGroup": "pipeline_utilization_level1",
>> +    "ScaleUnit": "100%"
>> +  },
>> +  {
>> +    "MetricName": "retiring",
>> +    "BriefDescription": "Fraction of dispatch slots used by ops that retired.",
>> +    "MetricExpr": "d_ratio(ex_ret_ops, total_dispatch_slots)",
>> +    "MetricGroup": "pipeline_utilization_level1",
>> +    "ScaleUnit": "100%"
>> +  },
>> +  {
>> +    "MetricName": "frontend_bound_latency",
>> +    "BriefDescription": "Fraction of dispatch slots that remained unused because of a latency bottleneck in the frontend (such as instruction cache or TLB misses).",
>> +    "MetricExpr": "d_ratio((6 * cpu@...no_dispatch_per_slot.no_ops_from_frontend\\,cmask\\=0x6@), total_dispatch_slots)",
>> +    "MetricGroup": "pipeline_utilization_level2;frontend_bound_level2",
> 
> From:
> https://perf.wiki.kernel.org/index.php/Top-Down_Analysis
> perhaps this should be in a group "frontend_bound_group", to make the
> drill down more obvious.
> 

Agreed. I'll try to keep the group naming familiar wherever possible.

>> +    "ScaleUnit": "100%"
>> +  },
>> +  {
>> +    "MetricName": "frontend_bound_bandwidth",
>> +    "BriefDescription": "Fraction of dispatch slots that remained unused because of a bandwidth bottleneck in the frontend (such as decode or op cache fetch bandwidth).",
>> +    "MetricExpr": "d_ratio(de_no_dispatch_per_slot.no_ops_from_frontend - (6 * cpu@...no_dispatch_per_slot.no_ops_from_frontend\\,cmask\\=0x6@), total_dispatch_slots)",
>> +    "MetricGroup": "pipeline_utilization_level2;frontend_bound_level2",
>> +    "ScaleUnit": "100%"
>> +  },
>> +  {
>> +    "MetricName": "bad_speculation_mispredicts",
>> +    "BriefDescription": "Fraction of dispatched ops that were flushed due to branch mispredicts.",
>> +    "MetricExpr": "d_ratio(bad_speculation * ex_ret_brn_misp, ex_ret_brn_misp + resyncs_or_nc_redirects)",
>> +    "MetricGroup": "pipeline_utilization_level2;bad_speculation_level2",
>> +    "ScaleUnit": "100%"
>> +  },
>> +  {
>> +    "MetricName": "bad_speculation_pipeline_restarts",
>> +    "BriefDescription": "Fraction of dispatched ops that were flushed due to pipeline restarts (resyncs).",
>> +    "MetricExpr": "d_ratio(bad_speculation * resyncs_or_nc_redirects, ex_ret_brn_misp + resyncs_or_nc_redirects)",
>> +    "MetricGroup": "pipeline_utilization_level2;bad_speculation_level2",
>> +    "ScaleUnit": "100%"
>> +  },
>> +  {
>> +    "MetricName": "backend_bound_memory",
>> +    "BriefDescription": "Fraction of dispatch slots that remained unused because of stalls due to the memory subsystem.",
>> +    "MetricExpr": "backend_bound * d_ratio(ex_no_retire.load_not_complete, ex_no_retire.not_complete)",
>> +    "MetricGroup": "pipeline_utilization_level2;backend_bound_level2",
> 
> Similarly there could be a "backend_bound_group", etc.
> 

Agreed.

- Sandipan

Powered by blists - more mailing lists