From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 43AD6E77182 for ; Thu, 12 Dec 2024 10:13:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=qvnbcj2YKmEAhtiQZ+x9+fw5EQpdgF2hcSYZ69DOFN0=; b=Mv9JYazGxGonAjqpzqrCkNfyDN oMFcq8OY6VVs7DAHsoik/nLsD2FpcL+gOmg6UfZ3eSqCKeiR6d/r5FpOgJwWcEapmq1EdJ3nDybpL 0X2mAHTlsOM6pIL9lH59vwdvoQrh1ShTihjudsFBrpmhO193XTsv07xTiKwmRjgQxJNc9OMA2z0fP 2iA+wgML2N7mYwjPF9IJ6fWpYJUlyYlkQSXHb4T6gGTtb4GmNN4HG0NX4BXzrGBQAwPU5M1Ss1SYn oFIXO2G4HfF4TVlY3Y3VvP4rHuquTBgBObgT6oihf9pwi4bvWycEnC0CABZtVLrXFuR9viqbR/JYU Io39htqQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tLgCU-000000000zJ-176q; Thu, 12 Dec 2024 10:13:42 +0000 Received: from nyc.source.kernel.org ([2604:1380:45d1:ec00::3]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tLgBQ-000000000pu-0Ywa for linux-arm-kernel@lists.infradead.org; Thu, 12 Dec 2024 10:12:37 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 1E51BA42710; Thu, 12 Dec 2024 10:10:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EA19C4CECE; Thu, 12 Dec 2024 10:12:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733998355; bh=pI0CmbiNGAceIkukqgmpuyvpA4axUQGsh7I3w5JgAa0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=h4BeYANovPTKYcwkpZN7ak0uJ5p9MrVFewFPknskoPuwVIq8Vg0xaUyOkPeOcSqvZ 1N+66kK65+7cfajzy6k9VtSK+0tjeejNyOHJhww+Z6UvJfHtbLfzDlM4swY5E+86Kc 25PDhxPKr2r1MUymedHAOy6LCzhVBbVWUtbIZprmxOn4WPC1Mh5069dz33g0FcOX0J MvLaSjlhbPSRxae6MriZIy7GtcDbSZzeh7lreO02oSJvC4uB9M5UHarmb45xV3wxaw 5C3phAiaeOYabII826uqaLooo1sCpA/AGAPi0y2MsnmGVr4F/zGMN1hPRKn2P/dL7I xAuR68oxFE7/A== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tLgBM-0031y9-Ph; Thu, 12 Dec 2024 10:12:33 +0000 Date: Thu, 12 Dec 2024 10:12:32 +0000 Message-ID: <86ldwlryzz.wl-maz@kernel.org> From: Marc Zyngier To: richard clark Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, "Russell King (Oracle)" , Mark Rutland , Linus Torvalds Subject: Re: Question about interrupt prioriyt of ARM GICv3/4 In-Reply-To: References: <86cyi5tanz.wl-maz@kernel.org> 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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: richard.xnu.clark@gmail.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, linux@armlinux.org.uk, mark.rutland@arm.com, torvalds@linux-foundation.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241212_021236_300521_CCF2DCA0 X-CRM114-Status: GOOD ( 46.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 12 Dec 2024 09:18:56 +0000, richard clark wrote: >=20 > Hi M, Hi r, >=20 > On Fri, Dec 6, 2024 at 5:37=E2=80=AFPM Marc Zyngier wrot= e: > > > > On Fri, 06 Dec 2024 08:33:11 +0000, > > richard clark wrote: > > > > > > Hi, > > > Currently seems the GICv3/4 irqchip configures all the interrupts as > > > the same priority, I am thinking about to minimize the latency of the > > > interrupt for a particular device, e.g, the arm arch_timer in the RTL > > > system. The question is, > > > 1. Why don't we provide a /proc or /sys interface for the enduser to > > > set the priority of a specific interrupt(SPI/PPI)? > > > > I'm afraid this really has nothing to do with any particular interrupt > > architecture. > > > > Before thinking of exposing the interrupt priority to userspace, you > > should look at what this translates into for the kernel once you allow > > interrupts to be preempted by another one with a higher priority. > > > Interrupt priority doesn't necessarily mean the preemption, seems > you're talking about the interrupt preemption harm according to your > statement followed.Frankly I am just thinking higher priority will win > the lower ones in case massive external interrupts received in the GIC > level (you see I am still talking about GIC, not kernel) As I stated at the end of my email, the GIC only gives guarantee that you will ack the highest priority interrupt in finite time. Not right when it is made pending. Yes, it has the concept of HPPI. But that from the PoV of the CPU interface, not that of the distributor. Factor in the Stream interface, and you realise that expecting to always ack the highest priority pending interrupt is akin to expecting no reordering of packets in a network. > > > > This means that at every point where you would normally see a > > local_irq_save(), spinlock_irqsave() or equivalent, you would need to > > explicitly specify the priority that you allow for preemption. You > > should then make sure that any code that can be run during an > > interrupt is reentrant. You need to define which data structures can > > be manipulated at which priority level... The list goes on. > > > irqsave just masks the interrupt from the point of cpu, I don't think > it will mess things up if preemption really happens (no? then what the > side-effect is for the nested interrupt handling in the softirq part. > damage the semantic of the lock primitives?) > > > > If you want a small taste of the complexity, just look at what > > handling NMIs (or even pseudo-NMIs in the case of GICv3) means, and > > generalise it to not just two, but an arbitrary range of priorities. > > > > If you want the full blown experience, look at the BSDs and their use > > of spl*(). I don't think anyone has any plan to get there, and the RT > > patches have shown that there is little need for it. > > > As supplement=EF=BC=8Cthe fiq is suggested to be used as an alternative t= o the > higher priority in the RT area... FIQ's dead, baby. FIQ's dead. > > > > > 2. Is there any way to verify the higher priority interrupt will have > > > more dominant to be selected to the CPU (IOW, the priority is really > > > working) in case of multiple different interrupts asserted to the GIC > > > at the same time(some debug registers of GIC like GICD_REEMPT_CNT :-) > > > to record higher priority wins)? > > > > The GIC architecture makes no promise that the interrupt you > > acknowledge is the highest priority pending interrupt, because this is > > by definition a very racy process. > > > > Also, even on busy systems, you will very rarely see two interrupts > > targeting the same CPU being made pending at the same time, so that > > the interrupt delivery system would have to arbitrate between the two. > > That's because interrupts are vanishingly rare in the grand scheme of > > things. > > > 1. I am trying to stress the external interrupts to the core#0 via the > stress-ng tool with one of interrupt being configured as higher > priority to see the benchmark data, it's time consuming as you can > image, still is in progress(BTW, I can't see any lockup similar hang > in the system with a higher priority configured) If you don't have preemption, I don't think anything wrong will happen. But I don't expect any benefit either. > 2. This raises a very interesting question and I am also very curious > about is, what is the purpose for the GIC to introduce the interrupt > priority features, a placeholder feature reserved for the future? Ah, > hardware prefer to provide more functionalities than its being > actually used by software, any other justification except that? You realise that the HW is not exclusively designed for Linux, right? M. --=20 Without deviation from the norm, progress is not possible.