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 0A673E77173 for ; Fri, 6 Dec 2024 09:38:25 +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-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=LS6+0C7sOHJODg52W5usnubigPgJaQONk5sHQ043Pmc=; b=nYzMOBn+ykcqPMfZiiBuU/kmpV LZqfelXK4wsJfZapE8yxYlENBUMAMIyoAnipJU8TZacIHofMeh4QlLwI5wSb1K7lllUu8HfClteTU VYMYqDcvU/rwd0EuFHb16THG2YXriRjR4oFLBJ6aSAvJ777gjJSimTbV2TTkXbirYaT/tNc6vBYac q18DPxwx2mVBNTInKziqQMBvjT6Rigs2n/HFllxE+6MXRSltcq0nbQ0dMH67y46Pm4hgVkDhfN6yZ iEveoVYfkXoJTDoxxqtmKCLltuPAlw1wwOJeF7A4k0vWv5J9X/kKE32pf7EZOeeLLU1pXmiwBJ0JY dZsEGXXQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tJUmp-000000016YT-3f2h; Fri, 06 Dec 2024 09:38:11 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tJUlo-000000016Gt-1BBY for linux-arm-kernel@lists.infradead.org; Fri, 06 Dec 2024 09:37:09 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 98A015C7283; Fri, 6 Dec 2024 09:36:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 12B9BC4CED1; Fri, 6 Dec 2024 09:37:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733477827; bh=0OVqSdKjz29ID2mDogu1rbXECrb7mkjLRUFXqkvFw88=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QasvlkzwlSXhBS1XlZ6BrGuaxJd0Hl6wlwXggvqdPyoPJum3dEyJqOX1JA9eUZ5UB XfhDfOQKeN0ftjlp58am78mCVZFIC0UIISRG1V5z3+RQIyAZ5fIGatx+J+ZR7SvquL eXc1Ew1jcvXPmRz6Tjga7mBtMeATzUHsy73hR/ym5YYUxqifn8BbKxkUmhKsS4p80Y cNqSHMjl86KXKcNgAkZgFP5or6y2P4t4UkV87hVSCB2+l17/ct4AQlyez8pM9MRa0W QXuJyhm43Eh9JyZZBpeoOexfIsvHzlUuRzy+Xo0hg06nDirVlb6UQq6ksPJPhmzz7O OKgj8qL5wbUKQ== 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 1tJUlk-0016ib-Gf; Fri, 06 Dec 2024 09:37:04 +0000 Date: Fri, 06 Dec 2024 09:37:04 +0000 Message-ID: <86cyi5tanz.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: 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=US-ASCII 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-20241206_013708_402473_CE63128C X-CRM114-Status: GOOD ( 25.68 ) 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 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. 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. 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. > 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. Thanks, M. -- Without deviation from the norm, progress is not possible.