On Wed, Sep 10, 2025 at 1:10 PM Namhyung Kim <namhyung@xxxxxxxxxx> wrote: > A nit. Can we have one actual event and an alias of it? > > I think 'branch-instructions' will be the actual event and 'branches' > will be the alias. Then the description will be like > > branch-instructions > [Retired branch instructions. Unit: cpu_atom] > ... > > branches > [This event is an alias of branch-instructions.] > > The same goes to 'cycles' and 'cpu-cycles'. Similar 'cs' and 'context-switches' in tools/perf/pmu-events/arch/common/common/software.json. So there are a few different ways to do this: 1) In perf list detect two events have the same encoding and list them together. 2) In the json have a new aliases list then either: 2.1) gets expanded in jevents.py as part of the build, 2.2) passes into the pmu-events.c and the C code is updated to use an alias list associated with each event. Option (1) will have something like quadratic complexity, but a fast perf list isn't a particular goal I've heard of. Option (2.2) will mean the existing binary searches for events will become a binary search for an event and then linear searches through the aliases. To make this not a slowdown we'd likely need more lookup tables to avoid the linear searches. Option (2.1) feels the most plausible. I was hoping the json and the sysfs layout would kind of match, this would be true after the jevents.py expands the aliases. This option is already kind of already done in the legacy cache case as the tools/perf/pmu-events/make_legacy_cache.py is making this. We'd still need option (1) with this. Anyway, I'm not sure these downsides are countered by a slightly smaller hardware.json and software.json, or maybe we should just go with option 1 if the perf list output is all you care about. Let me know if you see a different way of making it happen. I don't think the vendors will be particularly happy for their upstream formats to change given other tools will rely on them. Thanks, Ian
