linux-kernel - Re: Question on the scheduling of timer interrupt and FIO interrupt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <917dfd6e-b8be-03b0-bfda-ce1108693bc2@huawei.com>
Date: Mon, 4 Aug 2025 11:27:14 +0800
From: Zenghui Yu <yuzenghui@...wei.com>
To: Marc Zyngier <maz@...nel.org>
CC: wangwudi <wangwudi@...ilicon.com>, Thomas Gleixner <tglx@...utronix.de>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
	<yangwei24@...wei.com>, <yaohongshi@...ilicon.com>, Zenghui Yu
	<zenghui.yu@...ux.dev>
Subject: Re: Question on the scheduling of timer interrupt and FIO interrupt

Hi Marc,

On 2025/8/1 20:01, Marc Zyngier wrote:
> + Zenghui, in case he has seen this before.

I haven't heard of it before.

> On Fri, 01 Aug 2025 07:26:20 +0100,
> wangwudi <wangwudi@...ilicon.com> wrote:
> >
> > Hi, all
> > When running some FIO tests on ARM64 server(Kunpeng), frequent NVMe interrupts occupy the
> > CPU, and the CPU's hardirq load is 100%. The watchdog feed interrupt arch_timer cannot be
> > responded, triggering the hardlockup.
> 
> I am extremely surprised that even with a screaming NVMe (or even
> several of them), you end up in a situation where you don't have the
> resource to take the timer interrupt.

+1. I will probably have an offline discussion with Wudi today, or a bit
later, to dig out more clues about it.

> > GIC driver uses GICV3_PRIO_IRQ to set the same priority for arch_timer interrupt and NVMe
> > interrupt. In GIC spec, "If, on a particular CPU interface, multiple pending interrupts
> > have the same priority, and have sufficient priority for the interface to signal them to
> > the PE, it is IMPLEMENTATION DEFINED how the interface selects which interrupt to signal."
> > Shell we consider setting a higher priority for the arch_timer interrupt to fix this case?
> 
> Linux only deals with two priorities: the normal interrupt priority,
> and NMI, where the NMI can preempt any other interrupt. obviously, we
> don't want to make the timer an NMI, as it would break a lot of
> things.
> 
> Which means that even if you were to give the timer a higher priority,
> it should not be allowed to preempt any other interrupt. Which means
> that you'd need to set the binary point so that both the NVMe and
> timer priorities fall into the same preemption bucket.
> 
> But it also means that you now are eating into the few bits of
> priority that we have, and that will cause problems with the NMI
> priority. Also, how to you decide what interrupts should be of a
> higher priority?
> 
> I find it surprising that your GIC doesn't have some form of
> round-robin scheme to pick the next HPPI, because that's clearly a
> fairness problem, and punting that on SW is pretty ugly.
> 
> Thanks,
> 
> 	M.
>