Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 09 Oct 2022 03:13:29 +0100
Message-ID: <87tu4dhhh2.wl-maz@kernel.org>
From:   Marc Zyngier <maz@kernel.org>
To:     "=?utf-8?B?WmhhbmcgWGluY2hlbmc=?=" <zhangxincheng@uniontech.com>
Cc:     "=?utf-8?B?dGdseA==?=" <tglx@linutronix.de>,
        "=?utf-8?B?bGludXgta2VybmVs?=" <linux-kernel@vger.kernel.org>,
        "=?utf-8?B?b2xla3NhbmRy?=" <oleksandr@natalenko.name>,
        "=?utf-8?B?SGFucyBkZSBHb2VkZQ==?=" <hdegoede@redhat.com>,
        "=?utf-8?B?YmlnZWFzeQ==?=" <bigeasy@linutronix.de>,
        "=?utf-8?B?bWFyay5ydXRsYW5k?=" <mark.rutland@arm.com>,
        "=?utf-8?B?bWljaGFlbA==?=" <michael@walle.cc>
Subject: Re: [PATCH] interrupt: discover and disable very frequent interrupts
In-Reply-To: <tencent_48EE20EE67D50AC81A28CAAF@qq.com>
References: <20220930064042.14564-1-zhangxincheng@uniontech.com>
        <86bkqx6wrd.wl-maz@kernel.org>
        <tencent_7C4E401B708789BC3A26F57C@qq.com>
        <868rm16tbu.wl-maz@kernel.org>
        <tencent_48EE20EE67D50AC81A28CAAF@qq.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Sun, 09 Oct 2022 02:31:36 +0100,
"=?utf-8?B?WmhhbmcgWGluY2hlbmc=?=" <zhangxincheng@uniontech.com> 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@intel.com
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.