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

[Jonathan Cameron]

On Thu, 6 Apr 2023 19:08:45 +0200
Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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."
> > 
> > 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.
> > 
> > My overall favorite is an l2 cache related PMU that is spun up in
> > arch/arm/kernel/irq.c init_IRQ()
> > 
> > I'm just not going to try and figure out why...  
> 
> Why not change the api to force a parent to be passed in?  And if one
> isn't, we make it a "virtual" device and throw it in the class for them?

Longer term I'd be fine doing that, but I'd like to identify the right parents
rather than end up sweeping it under the carpet.  Anything we either get completely
stuck on (or decide we don't care about) could indeed fall back to a virtual
device.

Jonathan


> 
> thanks,
> 
> greg k-h