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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B0C4C433DF for ; Thu, 21 May 2020 15:12:29 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 3E03020748 for ; Thu, 21 May 2020 15:12:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="AZ5EMeEK"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="cvHO6Au5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3E03020748 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gdVSRrKX84SDjaJlfWtB8abXefrshQFQWYcoAxjgaKY=; b=AZ5EMeEK4FSo5L qi4SFymv7SWGQ2Qn+DLmL5SjjS17rvlW6utir/0O1NQlHZuP7djjCcqF3884lCdQYHkPcQ4ZjuzUK iAiMdMbTOcx//C9+x0/HnrYX8GTbD/HcPF9//wJ9HasHUdYxZT9HnBj5H0krO+BqxTnLZ7W+9IgZP Mp51+YngTZKEVW46qrS6osSxuvkSDwt18wZVu3vF5ffpJ5lxAvBA13H2KCOSr4DlS9Ohrhxhh+NVQ q8zY6sRKmS46CPRWI3cW4+CiwfnrEXpfiG4uUHHE2pRXjuXB5ltVggjmXDERooAh5Ax+avndBGbbL wnfXil7c0hcHSApYUd9g==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jbms0-0004sC-W7; Thu, 21 May 2020 15:12:28 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jbmrx-0004re-Sy for linux-arm-kernel@lists.infradead.org; Thu, 21 May 2020 15:12:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Vu0Vaxs7IefmouAAAzANzYnryWDduj56r+NgTrTYkZs=; b=cvHO6Au5II47Bw46tKmX9ddJY NNPdxihzF1xRveiO5KeHqkQRyrLIVwEyy5VIEQf/DPsQBWBqKyRKEnZKSI6ROgHy9rsiQH5t9pnPp qC5LFl+SiPr+9evpFbTP6Y5GGkzAU92ZQfe8ATLSxhlRcyI5MB4moG62SI1LAUbXAwjd04kNZ58pD Z2dkufbj1cPu/cjGQuwDTWn6lOi40EAFQ/tGgL1QsWstVf7UiQf8lLPsumuDOqBzuQExzdCgaCDrb i1XRYcPh50FYF3SGaZxQ3yyElk8ww08hnK/BDPx8Af4JLCGVK4ja/8mb9l2XKd/hJpa5R4wjIfnfn p9CbQ4Xrw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:35116) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbmrp-0002k7-0D; Thu, 21 May 2020 16:12:17 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jbmrk-0000Ix-EH; Thu, 21 May 2020 16:12:12 +0100 Date: Thu, 21 May 2020 16:12:12 +0100 From: Russell King - ARM Linux admin To: Valentin Schneider Subject: Re: [PATCH 04/11] ARM: Allow IPIs to be handled as normal interrupts Message-ID: <20200521151212.GT1551@shell.armlinux.org.uk> References: <20200519161755.209565-1-maz@kernel.org> <20200519161755.209565-5-maz@kernel.org> <20200519222447.GJ1551@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200521_081226_082321_D4D64ACE X-CRM114-Status: GOOD ( 21.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sumit Garg , kernel-team@android.com, Jason Cooper , Marc Zyngier , linux-kernel@vger.kernel.org, Catalin Marinas , Thomas Gleixner , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, May 21, 2020 at 03:03:49PM +0100, Valentin Schneider wrote: > > On 19/05/20 23:24, Russell King - ARM Linux admin wrote: > > On Tue, May 19, 2020 at 05:17:48PM +0100, Marc Zyngier wrote: > >> In order to deal with IPIs as normal interrupts, let's add > >> a new way to register them with the architecture code. > >> > >> set_smp_ipi_range() takes a range of interrupts, and allows > >> the arch code to request them as if the were normal interrupts. > >> A standard handler is then called by the core IRQ code to deal > >> with the IPI. > >> > >> This means that we don't need to call irq_enter/irq_exit, and > >> that we don't need to deal with set_irq_regs either. So let's > >> move the dispatcher into its own function, and leave handle_IPI() > >> as a compatibility function. > >> > >> On the sending side, let's make use of ipi_send_mask, which > >> already exists for this purpose. > > > > You say nothing about the nesting of irq_enter() and irq_exit() > > for scheduler_ipi(). > > > > Given that lockdep introduced the requirement that hard IRQs can't > > be nested, are we sure that calling irq_exit() twice is safe? > > > > Looking at irqtime_account_irq(), it seems that will cause double- > > accounting of in-interrupt time, since we will increment > > irq_start_time by just over twice the the period spent handling > > the IPI. > > > > I think the rest of irq_exit() should be safe, but still, this > > behaviour should be documented at the very least, if not avoided. > > > > x86 does the same (though IIUC only when tracing reschedule IPI's), Right, so when the system is operating normally, then the accounting is correct. When the reschedule path is being explicitly traced, then the accounting will be doubled for it. What's being proposed for ARM is to always have this mis-accounting, where no mis-accounting was present before - and some of us (me) /do/ enable IRQ accounting in our kernels as standard. So, you can take this as a kernel regression report from a user. > and MIPS has the same issue as it also uses generic IRQ IPI's - so > although it's not ideal, I think we can live with it. Yes, but is there anyone who cares about this for MIPS? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel