RE: [PATCH v3] perf: arm_cspmu: Separate Arm and vendor module

[Besar Wicaksono]

Hi Robin,

> -----Original Message-----
> From: Robin Murphy <robin.murphy@xxxxxxx>
> Sent: Thursday, June 1, 2023 9:34 AM
> To: Besar Wicaksono <bwicaksono@xxxxxxxxxx>; suzuki.poulose@xxxxxxx;
> catalin.marinas@xxxxxxx; will@xxxxxxxxxx; mark.rutland@xxxxxxx
> Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-
> tegra@xxxxxxxxxxxxxxx; Thierry Reding <treding@xxxxxxxxxx>; Jonathan
> Hunter <jonathanh@xxxxxxxxxx>; Vikram Sethi <vsethi@xxxxxxxxxx>; Richard
> Wiley <rwiley@xxxxxxxxxx>; Eric Funsten <efunsten@xxxxxxxxxx>
> Subject: Re: [PATCH v3] perf: arm_cspmu: Separate Arm and vendor module
> 
> External email: Use caution opening links or attachments
> 
> 
> On 2023-05-08 18:04, Besar Wicaksono wrote:
> [...]
> >>> +obj-$(CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU) +=
> >> arm_cspmu_impl.o
> >>
> >> Not sure what's up with this... I have no complaint with keeping the
> >> impl infrastucture together in its own source file, but it still wants
> >> to end up as part of arm_cspmu_module. Doing otherwise just adds
> >> unnecessary overhead at many levels and invites more problems.
> >
> > My intention is to separate arm_cspmu_impl, arm_cspmu, and
> > vendor backend into different modules. Here is the dependency I have in
> mind:
> >
> >                                                 arm_cspmu_impl
> >                                                       ____|____
> >                                                      |                  |
> >                                      arm_cspmu               nvidia_cspmu
> >
> > This helps during device probe that the call to request_module can be made
> > as a blocking call and the backend init_impl_ops will always be ready to use
> after
> > request_module returns. The code seems simpler this way. Could you please
> > elaborate the potential issue that might arise with this approach?
> 
> I see the intent; the main issue is that the implementation of it is
> needlessly fiddly: arm_cspmu_impl is not useful on its own, and probably
> only represents a few hundred bytes of code, so putting in a distinct
> .ko which needs to be loaded separately is a relatively massive waste of
> filesystem space and memory for what it is. Also if anything that
> dependency is the wrong way round anyway - arm_cspmu could provide
> generic PMU functionality just fine regardless of arm_cspmu_impl, but
> arm_cspmu_impl definitely has a logical and functional dependency on
> arm_cspmu in order to serve any user-visible purpose.
> 

Thank you for the explanation. I will move the impl code back to arm_cspmu source file.
With that, we no longer can load the backend module synchronously, so I will use the
deferred probe approach as you suggested before.

Thanks,
Besar