Re: [PATCH 1/2] Revert "perf/core: Fix hardlockup failure caused by perf throttle"

[Peter Zijlstra <peterz@infradead.org>]

On Sat, Apr 05, 2025 at 10:16:34PM +0800, Qing Wong wrote:
> From: Qing Wang <wangqing7171@gmail.com>
> 
> This reverts commit 15def34e2635ab7e0e96f1bc32e1b69609f14942.
> 
> The hardlockup failure does not exist because:
> 1. The hardlockup's watchdog event is a pinned event, which exclusively
> occupies a dedicated PMC (Performance Monitoring Counter) and is unaffected
> by PMC scheduling.
> 2. The hardware event throttling mechanism only disables the specific PMC
> where throttling occurs, without impacting other PMCs. Consequently, The
> hardlockup event's dedicated PMC remains entirely unaffected.
> 
> Signed-off-by: Qing Wang <wangqing7171@gmail.com>
> ---
>  kernel/events/core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 0bb21659e252..29cdb240e104 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -10049,8 +10049,8 @@ __perf_event_account_interrupt(struct perf_event *event, int throttle)
>  		hwc->interrupts = 1;
>  	} else {
>  		hwc->interrupts++;
> -		if (unlikely(throttle &&
> -			     hwc->interrupts > max_samples_per_tick)) {
> +		if (unlikely(throttle
> +			     && hwc->interrupts >= max_samples_per_tick)) {

Well, it restores bad coding style. The referred commit also states that
max_samples_per_tick can be 1, at which point we'll always throttle the
thing, since we've just increased.

That is, the part of the old commit that argued about e050e3f0a71bf
flipped the compare and the increment is still true. So even though it
might not be related to the hardlockup problem, I still don't think the
patch was wrong.