Re: [PATCH 2/2] perf/core: Fix broken throttling when max_samples_per_tick=1
From: Peter Zijlstra
Date: Fri Apr 18 2025 - 05:03:37 EST
On Sat, Apr 05, 2025 at 10:16:35PM +0800, Qing Wong wrote:
> From: Qing Wang <wangqing7171@xxxxxxxxx>
>
> According to the throttling mechanism, the pmu interrupts number can not
> exceed the max_samples_per_tick in one tick. But this mechanism is
> ineffective when max_samples_per_tick=1, because the throttling check is
> skipped during the first interrupt and only performed when the second
> interrupt arrives.
>
> Perhaps this bug may cause little influence in one tick, but if in a
> larger time scale, the problem can not be underestimated.
>
> When max_samples_per_tick = 1:
> Allowed-interrupts-per-second max-samples-per-second default-HZ ARCH
> 200 100 100 X86
> 500 250 250 ARM64
> ...
> Obviously, the pmu interrupt number far exceed the user's expect.
>
> Fixes: e050e3f0a71b ("perf: Fix broken interrupt rate throttling")
> Signed-off-by: Qing Wang <wangqing7171@xxxxxxxxx>
> ---
> kernel/events/core.c | 17 ++++++++---------
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 29cdb240e104..4ac2ac988ddc 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -10047,16 +10047,15 @@ __perf_event_account_interrupt(struct perf_event *event, int throttle)
> if (seq != hwc->interrupts_seq) {
> hwc->interrupts_seq = seq;
> hwc->interrupts = 1;
> - } else {
> + } else
> hwc->interrupts++;
> - if (unlikely(throttle
> - && hwc->interrupts >= max_samples_per_tick)) {
> - __this_cpu_inc(perf_throttled_count);
> - tick_dep_set_cpu(smp_processor_id(), TICK_DEP_BIT_PERF_EVENTS);
> - hwc->interrupts = MAX_INTERRUPTS;
> - perf_log_throttle(event, 0);
> - ret = 1;
> - }
> +
> + if (unlikely(throttle && hwc->interrupts >= max_samples_per_tick)) {
> + __this_cpu_inc(perf_throttled_count);
> + tick_dep_set_cpu(smp_processor_id(), TICK_DEP_BIT_PERF_EVENTS);
> + hwc->interrupts = MAX_INTERRUPTS;
> + perf_log_throttle(event, 0);
> + ret = 1;
> }
Fair enough I suppose. I'll make this apply without that revert -- it
seems pointless to have that in between.