by Ian Rogers

[permalink] [raw]

Subject: Re: [PATCH 00/20] perf vendors events arm64: Multiple Arm CPUs

On Thu, May 19, 2022 at 6:53 AM Nick Forrington <[email protected]> wrote:
>
>
> On 19/05/2022 08:59, John Garry wrote:
> > On 18/05/2022 15:14, Robin Murphy wrote:
> >>> Sure, we should have these 32b cores supported for ARCH=arm if they
> >>> are supported for ARCH=arm64. But then does it even make sense to
> >>> have A7 support in arch/arm64?
> >>
> >> That's what I'm getting at. If it is tied to the build target as
> >> you've said above, then there is no point in an AArch64 perf tool
> >> including data for CPUs on which that tool cannot possibly run; it's
> >> simply a waste of space.
> >>
> >> If there is interest in plumbing in support on AArch32 builds as
> >> well, then I'd still be inclined to have a single arch/arm events
> >> directory, and either do some build-time path munging or just symlink
> >> an arch/arm64 sibling back to it. Yes, technically there are
> >> AArch64-only CPUs whose data would then be redundant when building
> >> for AArch32,
> >
> > If size is an issue then we have ways to cut this down, like doing the
> > arch standard events fixup dynamically when running perf tool, or even
> > not describing those events in the JSONs and rely on reading the CPU
> > PMU events folder to learn which of those events are supported.
> >
> > > but those are
> > > such a minority that it seems like an entirely reasonable compromise.
> >
> > @Nick, Can you drop the 32b core support for arm64? Or, if you really
> > want them, look into ARCH=arm pmu-events support?
>
> No problem - I'll resubmit without the 32b-only CPUs.
>
> Thanks,
> Nick
>

I'm hoping with jevents.py [1] then we can do a few things on the size front:

1) relocations - the current pattern of generating '.foo = "foo_Bar"'
means that when perf starts the .foo pointer needs to be updated for
the relocation. If we concatenate the strings together then we can
have 1 relocation, but we'll need an offset and length to get .foo's
value and some kind of iteration abstraction. If we do this then we
could also look to compress the string at compile time.
2) sorting events - not really a compiler size improvement but should
lower some runtime memory usage. We shouldn't need to linearly search
event names, sorting at compile time means we can locate faster, less
paging, etc.
3) we've spoken in the past of the problems of cross-architecture
testing of events, metrics, etc. For metrics, we may want to record
events on one architecture and compute metrics on another. One idea is
to have a fuller jevents mode where everything is built into one
binary, which would make size improvements more valuable.

Another thing with jevents.py is trying to make the pmu-events.c
presentation more consistent with sysfs', which may regress things on
size.

Anyway, I think it is good to have more events and I'm excited to see
this merged in a way that's suitable for John. I'm happy to do more
optionality stuff with jevents.py or the build if that can mean having
more events on ARM32.

Thanks,
Ian

[1] https://lore.kernel.org/linux-perf-users/[email protected]/
- show your love with Acked-bys :-D