Re: [PATCH V2 07/15] perf/arm: Remove driver-specific throttle support

[Leo Yan <leo.yan@arm.com>]

On Wed, May 14, 2025 at 08:13:53AM -0700, kan.liang@linux.intel.com wrote:
> From: Kan Liang <kan.liang@linux.intel.com>
> 
> The throttle support has been added in the generic code. Remove
> the driver-specific throttle support.
> 
> Besides the throttle, perf_event_overflow may return true because of
> event_limit. It already does an inatomic event disable. The pmu->stop
> is not required either.
> 
> Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Rob Herring (Arm) <robh@kernel.org>
> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Cc: Will Deacon <will@kernel.org>
> ---
>  drivers/perf/arm_pmuv3.c      | 3 +--
>  drivers/perf/arm_v6_pmu.c     | 3 +--
>  drivers/perf/arm_v7_pmu.c     | 3 +--
>  drivers/perf/arm_xscale_pmu.c | 6 ++----
>  4 files changed, 5 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
> index e506d59654e7..3db9f4ed17e8 100644
> --- a/drivers/perf/arm_pmuv3.c
> +++ b/drivers/perf/arm_pmuv3.c
> @@ -887,8 +887,7 @@ static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
>  		 * an irq_work which will be taken care of in the handling of
>  		 * IPI_IRQ_WORK.
>  		 */
> -		if (perf_event_overflow(event, &data, regs))
> -			cpu_pmu->disable(event);
> +		perf_event_overflow(event, &data, regs);

I did a test for Arm PMUv3, sometimes I can get consistent result
crossing events, but I still saw discrepancy in some runs:

   # perf record -c 400 -C 4,5,6,7 -e "{cycles,cycles}:S" -- sleep 5

   # perf report -D | grep PERF_RECORD_SAMPLE -a4 | tail -n 5
   7 5691046123610 0x63670 [0x68]: PERF_RECORD_SAMPLE(IP, 0x1): 0/0:
   0xffff80008137a6d0 period: 400 addr: 0
   ... sample_read:
   .... group nr 2
   ..... id 00000000000000bf, value 000000000019d7a7, lost 0
   ..... id 00000000000000c3, value 000000000019d3f9, lost 0

Though it does not dismiss discrepancy totally (maybe it depends on
hardware mechanism), I do see this series can mitigate the issue
significantly.

Tested-by: Leo Yan <leo.yan@arm.com>