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] [day] [month] [year] [list]
Message-ID: <40988c57-ee6f-4693-afe4-2615dc43f395@linaro.org>
Date: Wed, 28 Jan 2026 09:36:32 +0000
From: James Clark <james.clark@...aro.org>
To: Ian Rogers <irogers@...gle.com>, Besar Wicaksono <bwicaksono@...dia.com>
Cc: john.g.garry@...cle.com, will@...nel.org, mike.leach@...aro.org,
 leo.yan@...ux.dev, mark.rutland@....com, alexander.shishkin@...ux.intel.com,
 jolsa@...nel.org, adrian.hunter@...el.com, peterz@...radead.org,
 mingo@...hat.com, acme@...nel.org, namhyung@...nel.org,
 linux-tegra@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
 tmakin@...dia.com, vsethi@...dia.com, rwiley@...dia.com, skelley@...dia.com,
 ywan@...dia.com, treding@...dia.com, jonathanh@...dia.com, mochs@...dia.com
Subject: Re: [PATCH] perf vendor events arm64: Add Tegra410 Olympus PMU events



On 28/01/2026 8:03 am, Ian Rogers wrote:
> On Tue, Jan 27, 2026 at 3:00 PM Besar Wicaksono <bwicaksono@...dia.com> wrote:
>>
>> Add JSON files for NVIDIA Tegra410 Olympus core PMU events.
>> Also updated the common-and-microarch.json.
>>
>> Signed-off-by: Besar Wicaksono <bwicaksono@...dia.com>
>> ---
>>   .../arch/arm64/common-and-microarch.json      |  90 +++
>>   tools/perf/pmu-events/arch/arm64/mapfile.csv  |   1 +
>>   .../arch/arm64/nvidia/t410/branch.json        |  45 ++
>>   .../arch/arm64/nvidia/t410/brbe.json          |   6 +
>>   .../arch/arm64/nvidia/t410/bus.json           |  48 ++
>>   .../arch/arm64/nvidia/t410/exception.json     |  62 ++
>>   .../arch/arm64/nvidia/t410/fp_operation.json  |  78 ++
>>   .../arch/arm64/nvidia/t410/general.json       |  15 +
>>   .../arch/arm64/nvidia/t410/l1d_cache.json     | 122 +++
>>   .../arch/arm64/nvidia/t410/l1i_cache.json     | 114 +++
>>   .../arch/arm64/nvidia/t410/l2d_cache.json     | 134 ++++
>>   .../arch/arm64/nvidia/t410/ll_cache.json      | 107 +++
>>   .../arch/arm64/nvidia/t410/memory.json        |  46 ++
>>   .../arch/arm64/nvidia/t410/metrics.json       | 722 ++++++++++++++++++
>>   .../arch/arm64/nvidia/t410/misc.json          | 646 ++++++++++++++++
>>   .../arch/arm64/nvidia/t410/retired.json       |  94 +++
>>   .../arch/arm64/nvidia/t410/spe.json           |  42 +
>>   .../arm64/nvidia/t410/spec_operation.json     | 230 ++++++
>>   .../arch/arm64/nvidia/t410/stall.json         | 145 ++++
>>   .../arch/arm64/nvidia/t410/tlb.json           | 158 ++++
>>   20 files changed, 2905 insertions(+)
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/branch.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/brbe.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/bus.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/exception.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/fp_operation.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/general.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/l1d_cache.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/l1i_cache.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/l2d_cache.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/ll_cache.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/memory.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/metrics.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/misc.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/retired.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/spe.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/spec_operation.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/stall.json
>>   create mode 100644 tools/perf/pmu-events/arch/arm64/nvidia/t410/tlb.json
>>
>> diff --git a/tools/perf/pmu-events/arch/arm64/common-and-microarch.json b/tools/perf/pmu-events/arch/arm64/common-and-microarch.json
>> index 468cb085d879..6af15776ff17 100644
>> --- a/tools/perf/pmu-events/arch/arm64/common-and-microarch.json
>> +++ b/tools/perf/pmu-events/arch/arm64/common-and-microarch.json
>> @@ -179,6 +179,11 @@
>>           "EventName": "BUS_CYCLES",
>>           "BriefDescription": "Bus cycle"
>>       },
>> +    {
>> +        "EventCode": "0x001E",
>> +        "EventName": "CHAIN",
>> +        "BriefDescription": "Chain a pair of event counters."
>> +    },
> 
> Cool stuff :-)
> 
> For wider counters AMD does something similar, but should this be an
> implementation detail rather than an exposed event? How does it
> operate as an event?
> 

CHAIN should be excluded from the json, it's used internally by the 
driver when you want 64 bit counters. Userspace can't use it because it 
can't control where counters are placed to make sure they're adjacent.

> [snip]
>> diff --git a/tools/perf/pmu-events/arch/arm64/mapfile.csv b/tools/perf/pmu-events/arch/arm64/mapfile.csv
>> index bb3fa8a33496..7f0eaa702048 100644
>> --- a/tools/perf/pmu-events/arch/arm64/mapfile.csv
>> +++ b/tools/perf/pmu-events/arch/arm64/mapfile.csv
>> @@ -46,3 +46,4 @@
>>   0x00000000500f0000,v1,ampere/emag,core
>>   0x00000000c00fac30,v1,ampere/ampereone,core
>>   0x00000000c00fac40,v1,ampere/ampereonex,core
>> +0x000000004e0f0100,v1,nvidia/t410,core
>> diff --git a/tools/perf/pmu-events/arch/arm64/nvidia/t410/branch.json b/tools/perf/pmu-events/arch/arm64/nvidia/t410/branch.json
>> new file mode 100644
>> index 000000000000..532bc59dc573
>> --- /dev/null
>> +++ b/tools/perf/pmu-events/arch/arm64/nvidia/t410/branch.json
>> @@ -0,0 +1,45 @@
>> +[
>> +    {
>> +        "ArchStdEvent": "BR_MIS_PRED",
>> +        "PublicDescription": "The Event counts Branches which are speculatively executed and mis-predicted."
> 
> nit: The capitalization on Event and Branches, as well as other words,
> is a little unusual.
> 

If there's nothing specific to this CPU then the public description 
could be left out entierly. The common strings already say the same 
thing as this:

     {
         "PublicDescription": "Mispredicted or not predicted branch
                               speculatively executed",
         "EventCode": "0x10",
         "EventName": "BR_MIS_PRED",
         "BriefDescription": "Mispredicted or not predicted branch
                              speculatively executed"
     },


> [snip]
>> diff --git a/tools/perf/pmu-events/arch/arm64/nvidia/t410/metrics.json b/tools/perf/pmu-events/arch/arm64/nvidia/t410/metrics.json
>> new file mode 100644
>> index 000000000000..18c2fd58ee9e
>> --- /dev/null
>> +++ b/tools/perf/pmu-events/arch/arm64/nvidia/t410/metrics.json
>> @@ -0,0 +1,722 @@
>> +[
>> +    {
>> +        "MetricName": "backend_bound",
>> +        "MetricExpr": "100 * (STALL_SLOT_BACKEND / CPU_SLOT)",
>> +        "BriefDescription": "This metric is the percentage of total slots that were stalled due to resource constraints in the backend of the processor.",
>> +        "ScaleUnit": "1percent of slots",
>> +        "MetricGroup": "TopdownL1"
> 
> Note, on x86 we place TopdownL1 in the Default metric group so it is
> shown by `perf stat` when it isn't given events or metrics to compute.
> Perhaps you want to do something similar?
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/pmu-events/arch/x86/icelake/icl-metrics.json?h=tmp.perf-tools-next#n116
> 
> Thanks,
> Ian

That's currently true for the Arm topdown metrics in sbsa.json, but we 
probably don't actually want this because there aren't enough counters 
for the perf stat defaults plus topdown and it results in multiplexing 
and bad results.

I was planning to change it but we also don't currently expose the 
number of counters available either...



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ