[PATCH] perf vendor events arm64 AmpereOneX: Drop stale BPU_FLUSH_MEM_FAULT entry

[PATCH] perf vendor events arm64 AmpereOneX: Drop stale BPU_FLUSH_MEM_FAULT entry

[TAKANO Mitsuhiro]

AmpereOne carried BPU_FLUSH_MEM_FAULT for EventCode 0x121 until it was
renamed to GPC_FLUSH_MEM_FAULT in 10a149e4b4a9; that rename and the
AmpereOneX table were patches 3 and 4 of the same series, so the new file
kept the old name.

The result is a table that names the 0x121 counter twice:
ampereonex/core-imp-def.json has GPC_FLUSH_MEM_FAULT, and
ampereonex/memory.json adds BPU_FLUSH_MEM_FAULT with the same code and
the same description.  On AmpereOneX perf therefore lists two events for
one counter, one of them under a name the documentation does not use.
No metric and no other file refers to either name, so removing the stale
entry cannot change a metric.

It also leaves memory.json holding only the ArchStdEvent aliases the
other files of that kind carry: AmpereOne's memory.json has no raw
EventCode at all, and neither has any other file of the AmpereOneX set
except the ones where raw codes belong.

Nothing catches this at build time.  jevents.py asserts on duplicate
event names, but x86 repeats an EventCode for many events because the
code carries umask and unit bits (3756 times across its tables) and
powerpc repeats five codes, so a duplicate-code check is not possible.
arm64 is the only architecture where no table but this one repeats a
code.

Not tested on hardware: there is no AmpereOneX machine here, so perf was
not run against the real PMU.  The change only edits a JSON table; the
perf build was verified and the generated table for this PMU goes from
two names for 0x121 to one (rebuilt, counted in pmu-events.c).

Fixes: 16438b652b46 ("perf vendor events arm64 AmpereOneX: Add core PMU events and metrics")
Assisted-by: LLM
Signed-off-by: TAKANO Mitsuhiro <takano32@gmail.com>
---
 .../pmu-events/arch/arm64/ampere/ampereonex/memory.json     | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/memory.json b/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/memory.json
index 6c06bc928415..2a83782f51b0 100644
--- a/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/memory.json
+++ b/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/memory.json
@@ -33,11 +33,5 @@
     },
     {
         "ArchStdEvent": "MEM_ACCESS_CHECKED_WR"
-    },
-    {
-        "PublicDescription": "Flushes due to memory hazards",
-        "EventCode": "0x121",
-        "EventName": "BPU_FLUSH_MEM_FAULT",
-        "BriefDescription": "Flushes due to memory hazards"
     }
 ]

base-commit: f47d223627f80cb7a1eb14c585fe6cb35de5e984
-- 
2.53.0

Re: [PATCH] perf vendor events arm64 AmpereOneX: Drop stale BPU_FLUSH_MEM_FAULT entry

[sashiko-bot]

> AmpereOne carried BPU_FLUSH_MEM_FAULT for EventCode 0x121 until it was
> renamed to GPC_FLUSH_MEM_FAULT in 10a149e4b4a9; that rename and the
> AmpereOneX table were patches 3 and 4 of the same series, so the new file
> kept the old name.
> 
> The result is a table that names the 0x121 counter twice:
> ampereonex/core-imp-def.json has GPC_FLUSH_MEM_FAULT, and
> ampereonex/memory.json adds BPU_FLUSH_MEM_FAULT with the same code and
> the same description.  On AmpereOneX perf therefore lists two events for
> one counter, one of them under a name the documentation does not use.
> No metric and no other file refers to either name, so removing the stale
> entry cannot change a metric.
> 
> It also leaves memory.json holding only the ArchStdEvent aliases the
> other files of that kind carry: AmpereOne's memory.json has no raw
> [ ... ]
> two names for 0x121 to one (rebuilt, counted in pmu-events.c).
> 
> Fixes: 16438b652b46 ("perf vendor events arm64 AmpereOneX: Add core PMU events and metrics")
> Assisted-by: LLM
> Signed-off-by: TAKANO Mitsuhiro <takano32@gmail.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261021224527.167637-1-takano32@gmail.com?part=1

Re: [PATCH] perf vendor events arm64 AmpereOneX: Drop stale BPU_FLUSH_MEM_FAULT entry

[Arnaldo Carvalho de Melo]

On Wed, Oct 21, 2026 at 10:45:27PM +0000, TAKANO Mitsuhiro wrote:
> AmpereOne carried BPU_FLUSH_MEM_FAULT for EventCode 0x121 until it was
> renamed to GPC_FLUSH_MEM_FAULT in 10a149e4b4a9; that rename and the
> AmpereOneX table were patches 3 and 4 of the same series, so the new file
> kept the old name.
> 
> The result is a table that names the 0x121 counter twice:
> ampereonex/core-imp-def.json has GPC_FLUSH_MEM_FAULT, and
> ampereonex/memory.json adds BPU_FLUSH_MEM_FAULT with the same code and
> the same description.  On AmpereOneX perf therefore lists two events for
> one counter, one of them under a name the documentation does not use.
> No metric and no other file refers to either name, so removing the stale
> entry cannot change a metric.
> 
> It also leaves memory.json holding only the ArchStdEvent aliases the
> other files of that kind carry: AmpereOne's memory.json has no raw
> EventCode at all, and neither has any other file of the AmpereOneX set
> except the ones where raw codes belong.
 
> Nothing catches this at build time.  jevents.py asserts on duplicate
> event names, but x86 repeats an EventCode for many events because the
> code carries umask and unit bits (3756 times across its tables) and
> powerpc repeats five codes, so a duplicate-code check is not possible.
> arm64 is the only architecture where no table but this one repeats a
> code.

Maybe a followup improvement to jevents.py?
 
> Not tested on hardware: there is no AmpereOneX machine here, so perf was
> not run against the real PMU.  The change only edits a JSON table; the
> perf build was verified and the generated table for this PMU goes from
> two names for 0x121 to one (rebuilt, counted in pmu-events.c).

Ilkka, can I have your Reviewed-by or Acked-by?

Thanks,

- Arnaldo
 
> Fixes: 16438b652b46 ("perf vendor events arm64 AmpereOneX: Add core PMU events and metrics")
> Assisted-by: LLM
> Signed-off-by: TAKANO Mitsuhiro <takano32@gmail.com>
> ---
>  .../pmu-events/arch/arm64/ampere/ampereonex/memory.json     | 6 ------
>  1 file changed, 6 deletions(-)
> 
> diff --git a/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/memory.json b/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/memory.json
> index 6c06bc928415..2a83782f51b0 100644
> --- a/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/memory.json
> +++ b/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/memory.json
> @@ -33,11 +33,5 @@
>      },
>      {
>          "ArchStdEvent": "MEM_ACCESS_CHECKED_WR"
> -    },
> -    {
> -        "PublicDescription": "Flushes due to memory hazards",
> -        "EventCode": "0x121",
> -        "EventName": "BPU_FLUSH_MEM_FAULT",
> -        "BriefDescription": "Flushes due to memory hazards"
>      }
>  ]
> 
> base-commit: f47d223627f80cb7a1eb14c585fe6cb35de5e984
> -- 
> 2.53.0

Re: [PATCH] perf vendor events arm64 AmpereOneX: Drop stale BPU_FLUSH_MEM_FAULT entry

[Ian Rogers]

On Tue, Oct 27, 2026 at 1:34 PM Arnaldo Carvalho de Melo
<acme@kernel.org> wrote:
>
> On Wed, Oct 21, 2026 at 10:45:27PM +0000, TAKANO Mitsuhiro wrote:
> > AmpereOne carried BPU_FLUSH_MEM_FAULT for EventCode 0x121 until it was
> > renamed to GPC_FLUSH_MEM_FAULT in 10a149e4b4a9; that rename and the
> > AmpereOneX table were patches 3 and 4 of the same series, so the new file
> > kept the old name.
> >
> > The result is a table that names the 0x121 counter twice:
> > ampereonex/core-imp-def.json has GPC_FLUSH_MEM_FAULT, and
> > ampereonex/memory.json adds BPU_FLUSH_MEM_FAULT with the same code and
> > the same description.  On AmpereOneX perf therefore lists two events for
> > one counter, one of them under a name the documentation does not use.
> > No metric and no other file refers to either name, so removing the stale
> > entry cannot change a metric.
> >
> > It also leaves memory.json holding only the ArchStdEvent aliases the
> > other files of that kind carry: AmpereOne's memory.json has no raw
> > EventCode at all, and neither has any other file of the AmpereOneX set
> > except the ones where raw codes belong.
>
> > Nothing catches this at build time.  jevents.py asserts on duplicate
> > event names, but x86 repeats an EventCode for many events because the
> > code carries umask and unit bits (3756 times across its tables) and
> > powerpc repeats five codes, so a duplicate-code check is not possible.
> > arm64 is the only architecture where no table but this one repeats a
> > code.
>
> Maybe a followup improvement to jevents.py?

It is expected that events may share an event code but they may be
differentiated by unit masks, filters, etc. We might have identical
encodings even with these extra differentiators, due to old and new
event names.

> > Not tested on hardware: there is no AmpereOneX machine here, so perf was
> > not run against the real PMU.  The change only edits a JSON table; the
> > perf build was verified and the generated table for this PMU goes from
> > two names for 0x121 to one (rebuilt, counted in pmu-events.c).
>
> Ilkka, can I have your Reviewed-by or Acked-by?

An alternative to deleting the event is to add:
"Deprecated": "1",
as that makes the event not show up in perf list. Using Deprecated
means that anyone using the event name won't be broken by this change.

Thanks,
Ian

Re: [PATCH] perf vendor events arm64 AmpereOneX: Drop stale BPU_FLUSH_MEM_FAULT entry

[Ilkka Koskinen]

[-- Attachment #1: Type: text/plain, Size: 2713 bytes --]


On Tue, 27 Oct 2026, Ian Rogers wrote:
> On Tue, Oct 27, 2026 at 1:34 PM Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
>>
>> On Wed, Oct 21, 2026 at 10:45:27PM +0000, TAKANO Mitsuhiro wrote:
>>> AmpereOne carried BPU_FLUSH_MEM_FAULT for EventCode 0x121 until it was
>>> renamed to GPC_FLUSH_MEM_FAULT in 10a149e4b4a9; that rename and the
>>> AmpereOneX table were patches 3 and 4 of the same series, so the new file
>>> kept the old name.
>>>
>>> The result is a table that names the 0x121 counter twice:
>>> ampereonex/core-imp-def.json has GPC_FLUSH_MEM_FAULT, and
>>> ampereonex/memory.json adds BPU_FLUSH_MEM_FAULT with the same code and
>>> the same description.  On AmpereOneX perf therefore lists two events for
>>> one counter, one of them under a name the documentation does not use.
>>> No metric and no other file refers to either name, so removing the stale
>>> entry cannot change a metric.
>>>
>>> It also leaves memory.json holding only the ArchStdEvent aliases the
>>> other files of that kind carry: AmpereOne's memory.json has no raw
>>> EventCode at all, and neither has any other file of the AmpereOneX set
>>> except the ones where raw codes belong.
>>
>>> Nothing catches this at build time.  jevents.py asserts on duplicate
>>> event names, but x86 repeats an EventCode for many events because the
>>> code carries umask and unit bits (3756 times across its tables) and
>>> powerpc repeats five codes, so a duplicate-code check is not possible.
>>> arm64 is the only architecture where no table but this one repeats a
>>> code.
>>
>> Maybe a followup improvement to jevents.py?
>
> It is expected that events may share an event code but they may be
> differentiated by unit masks, filters, etc. We might have identical
> encodings even with these extra differentiators, due to old and new
> event names.
>
>>> Not tested on hardware: there is no AmpereOneX machine here, so perf was
>>> not run against the real PMU.  The change only edits a JSON table; the
>>> perf build was verified and the generated table for this PMU goes from
>>> two names for 0x121 to one (rebuilt, counted in pmu-events.c).
>>
>> Ilkka, can I have your Reviewed-by or Acked-by?
>
> An alternative to deleting the event is to add:
> "Deprecated": "1",
> as that makes the event not show up in perf list. Using Deprecated
> means that anyone using the event name won't be broken by this change.

Sorry, I somehow missed the original email.


Takano, thanks for the patch!

That seems like a bug I made, when I tried to address the specification 
change. I'm fine with either option, taking the patch or set the event to 
"Deprecated".


Acked-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>

Cheers, Ilkka