在 2022/11/22 下午10:00, James Clark 写道:

On 21/11/2022 17:55, John Garry wrote:

quoted

On 21/11/2022 15:17, Jing Zhang wrote:

quoted

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:

I would agree with not having this and just hard coding the 5 wherever
it's needed. Once we have a few different sets of metrics in place maybe
we can start to look at deduplication, but for now I don't see the value.

quoted

+ 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)",
    },

quoted

+       }
+       {
+               "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.

For what we're going to publish shortly we'll be generating a
metrics.json file for each CPU. It will be autogenerated so I don't
think duplication will be an issue and I'm expecting that there will be
differences in the topdown metrics between CPUs anyway. So I would also
vote to not put it in recommended.json

I will create a new sbsa.json file in tools/perf/pmu-events/arch/arm64/
to place metrics that may be common between some CPUs, just like arch_std_event.
If the topdown metrics are different in other CPUs, we can overwrite the
metric expression.

For example:

+++ b/tools/perf/pmu-events/arch/arm64/sbsa.json

@@ -0,0 +1,9 @@
+[
+    {
+        "MetricExpr": "stall_slot_frontend / (slot * cpu_cycles)",
+        "PublicDescription": "Frontend bound L1 topdown metric",
+        "BriefDescription": "Frontend bound L1 topdown metric",
+        "MetricGroup": "TopDownL1",
+        "MetricName": "FRONTEND_BOUND"
+    }
+]

+ 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)",
+   }
+]

In addition, I can also add TLB, Cache, Branch, InstructionMix, PEutilization
and other metric groups into sbsa.json, because they are also applicable to
neoverse-n1. Above metrics are described in the documentation of neoverse-n1:
https://developer.arm.com/documentation/PJDOC-466751330-547673/r4p1/


Thanks,
Jing

quoted

quoted

Looking forward to your reply.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel