Re: [PATCH] interrupt: discover and disable very frequent interrupts

[Marc Zyngier]

On Sun, 09 Oct 2022 02:31:36 +0100,
"=?utf-8?B?WmhhbmcgWGluY2hlbmc=?=" <zhangxincheng@xxxxxxxxxxxxx> wrote:
> 
> > Again: what makes you think that it is better to kill the interrupt
> > than suffering a RCU stall? Yes, that's a lot of interrupts. But
> > killing it and risking the whole system isn't an acceptable outcome.
> 
> It's really not good to kill interrupts directly.

I'm glad you finally agree, (202210081220.9da0a329-yujie.liu@xxxxxxxxx
has a good example of a perfectly working machine that your patch
kills for no reason).

> Perhaps a better way is
> to report it and let the system administrator decide what to do with it.
> 
> + if((desc->gap_count & 0xffff0000) == 0)
> + desc->gap_time = get_jiffies_64();
> +
> + desc->gap_count ++;
> +
> + if((desc->gap_count & 0x0000ffff) >= 2000) {
> + if((get_jiffies_64() - desc->gap_time) < HZ) {
> + desc->gap_count += 0x00010000;
> + desc->gap_count &= 0xffff0000;
> + } else {
> + desc->gap_count = 0;
> + }
> +
> + if((desc->gap_count >> 16) > 30) {
> + __report_bad_irq(desc, action_ret, KERN_ERR "irq %d: triggered too frequently\n");
> + }
> + }
> +

I don't think this is much better. You hardcode values that only make
sense on your HW, and for nobody else. And what can the user do with
this message? Nothing at all. The message itself only contributes to
problem. As it is, this patch is only a nuisance.

As I said before, this would be much better as a rate-limiter, with
configurable limits, and behind a debug option.

	M.

-- 
Without deviation from the norm, progress is not possible.