Re: [PATCH 01/32] perf: Allow a PMU to have a parent

From: Robin Murphy
Date: Wed Jun 07 2023 - 07:03:25 EST


On 2023-06-06 14:48, Peter Zijlstra wrote:
On Tue, Jun 06, 2023 at 02:30:52PM +0100, Mark Rutland wrote:

Uh, *which* CPU device? Do we have a container device for all CPUs?

drivers/base/cpu.c:per_cpu(cpu_sys_devices, cpu) for whatever the core
pmu is for that cpu ?

... but the struct pmu covers several CPUs, so I don't have a single 'cpu', no?

If I have a system where cpu{0,1,2} are Cortex-A53 and cpu{3,4} are Cortex-A57,
I have two struct pmu instances, each associated with several CPUs. When I
probe each of those I determine a cpumask for each.

Bah :/ Clearly I overlooked the disparity there.

My overall favorite is an l2 cache related PMU that is spun up in
arch/arm/kernel/irq.c init_IRQ()

That's an artifact of the L2 cache controller driver getting initialized there;
ideally we'd have a device for the L2 cache itself (which presumably should
hang off an aggregate CPU device).

/sys/devices/system/cpu/cpuN/cache/indexM

has a struct device somewhere in
drivers/base/cacheinfo.c:ci_index_dev or somesuch.

I guess, but I don't think the L2 cache controller (the PL310) is actually tied
to that today.

All it would do is make fancy links in sysfs I think, who cares ;-)

Yeah, we're going to have a ton of them as well. Some of them are PCI
devices and have a clear parent, others, not so much :/

In a number of places the only thing we have is the PMU driver, and we don't
have a driver (or device) for the HW block it's a part of. Largely that's
interconnect PMUs; we could create container devices there.

Dont they have a PCI device? But yeah, some are going to be a wee bit
challenging.

The system might not even have PCI, so it's arguable that they should just hang
off an MMIO bus (which is effectively what the platofrm bus is).

You and your dodgy platforms :-)

For system PMUs we'll pretty much always have a platform device corresponding to a DT/ACPI entry used to describe MMIO registers and/or interrupts. In many cases the PMU is going to be the only part of the underlying device that is meaningful to Linux anyway, so I don't see any issue with just hanging the PMU device off its corresponding platform device - it still gives the user a way to map a PMU instance back to some understandable system topology (i.e. ACPI/DT) to disambiguate, and that's the most important thing.

Thanks,
Robin.