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

Mark Rutland mark.rutland at arm.com
Tue Jun 6 06:30:52 PDT 2023


On Tue, Jun 06, 2023 at 03:18:59PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 06, 2023 at 02:06:24PM +0100, Mark Rutland wrote:
> > On Thu, Apr 06, 2023 at 09:49:38PM +0200, Peter Zijlstra wrote:
> > > On Thu, Apr 06, 2023 at 05:44:45PM +0100, Jonathan Cameron wrote:
> > > > On Thu, 6 Apr 2023 14:40:40 +0200
> > > > Peter Zijlstra <peterz at infradead.org> wrote:
> > > > 
> > > > > On Thu, Apr 06, 2023 at 11:16:07AM +0100, Jonathan Cameron wrote:
> > > > > 
> > > > > > In the long run I agree it would be good.  Short term there are more instances of
> > > > > > struct pmu that don't have parents than those that do (even after this series).
> > > > > > We need to figure out what to do about those before adding checks on it being
> > > > > > set.  
> > > > > 
> > > > > Right, I don't think you've touched *any* of the x86 PMUs for example,
> > > > > and getting everybody that boots an x86 kernel a warning isn't going to
> > > > > go over well :-)
> > > > > 
> > > > 
> > > > It was tempting :) "Warning: Parentless PMU: try a different architecture."
> > > 
> > > Haha!
> > > 
> > > > I'd love some inputs on what the x86 PMU devices parents should be?
> > > > CPU counters in general tend to just spin out of deep in the architecture code.
> > > 
> > > For the 'simple' ones I suppose we can use the CPU device.
> > 
> > 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.

> > > > 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.

> > > 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).

Thanks,
Mark.



More information about the linux-arm-kernel mailing list