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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 2BEC9C3E8C5 for ; Fri, 27 Nov 2020 19:45:06 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 C258324137 for ; Fri, 27 Nov 2020 19:45:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="dQj2bOH9"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="yzOuRLDl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C258324137 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=scjQad6dBvSxXWqsCjRZ28HTRXiiJb+4R4ykYbPfMJg=; b=dQj2bOH9guIUGQ7e/gWwa3vig FZE8IjbpVW/mGTGHAMR3sU1isMxk9zNh4/MT+wBnAh9SouwNBeLynZLaaf9yhzXUY8SFdkJYpBjvK iDLN5OAaXpYXVx6wZJD28cBnTbPRFBu+BFqhUfaXSAKCHM63kqJm10teb5RrEHwqV4+1a/g9QOLPP FjB8XNRquJzprtMfQoDJbKyFA/Z02XoqbVRJQjoCxfn4/iX/8JbvvIk/WKf36d5ZYHWzjqfKnAhln oxJZ41UJN8J6ud33weAjk2a6zr7hT7COzzV5ZRRAOOwcE0AybwotayCnTGTOPSi+oAv0MK/r8LJzt ZoewjotVw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kijej-0005jt-Ad; Fri, 27 Nov 2020 19:43:45 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kijeh-0005jQ-8v; Fri, 27 Nov 2020 19:43:44 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1275D24101; Fri, 27 Nov 2020 19:43:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606506222; bh=7ujO+KYr0YlgsozIs8GtOPMUFRnhc+7f76/at6EGjss=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=yzOuRLDlBY/lQvtkbXcRWppVCTvoqXGJhgcJc4Q2PhCCeDP4gQ/T+HvVXDArxv744 yakYiDQcJJzrjncJ1/FAUFxxs4/2JWkDf28VtCu0lYifHffnQ4V2nz4jv7Rs+GoJEE bVa5VV9wbXRsJQQIhPS6Yoij9cx+9aHBLTCy9P0I= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kijee-00E99B-5i; Fri, 27 Nov 2020 19:43:40 +0000 MIME-Version: 1.0 Date: Fri, 27 Nov 2020 19:43:40 +0000 From: Marc Zyngier To: Catalin Marinas Subject: Re: [PATCH v1 1/3] irqchip/gic: enable irq target all In-Reply-To: <20201127185610.GA30096@gaia> References: <1606486531-25719-1-git-send-email-hanks.chen@mediatek.com> <1606486531-25719-2-git-send-email-hanks.chen@mediatek.com> <20201127185610.GA30096@gaia> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: catalin.marinas@arm.com, hanks.chen@mediatek.com, tglx@linutronix.de, matthias.bgg@gmail.com, linux@armlinux.org.uk, will@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, cc.hwang@mediatek.com, kuohong.wang@mediatek.com, loda.chou@mediatek.com 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-20201127_144343_462308_7BBF04A0 X-CRM114-Status: GOOD ( 20.96 ) 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: Mark Rutland , CC Hwang , Loda Chou , Hanks Chen , Kuohong Wang , Russell King , linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, Matthias Brugger , Thomas Gleixner , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-11-27 18:56, Catalin Marinas wrote: > On Fri, Nov 27, 2020 at 06:11:01PM +0000, Marc Zyngier wrote: >> On 2020-11-27 14:15, Hanks Chen wrote: >> > Support for interrupt distribution design for SMP system solutions. >> >> As far as I know, we have been supporting interrupt distribution on >> ARM SMP systems pretty well for the past... what... 15 years? >> I'm sure Russell can dig out an ARM926 SMP system that even predates >> that. >> >> > With this feature enabled ,the SPI interrupts would be routed to >> > all the cores rather than boot core to achieve better >> > load balance of interrupt handling. >> >> Please quantify this compared to the current distribution method. >> >> > That is, interrupts might be serviced simultaneously on different CPUs. >> >> They already can. What is new here? Or do you mean the *same* >> interrupt >> being serviced by different CPUs *at the same time*? That'd be fun. > > IIRC (it's been many years since I looked at the GIC), more than one > CPU > is woken and if they all read the INTACK, only one of them gets the > actual IRQ number, the others see a spurious interrupt. I thought we > decided that's not an efficient way to handle interrupts, so a software > irqbalancer is better. > > Has anything changed since then? What you describe is mostly the GICv1/v2 behaviour. GICv3 *can* be slightly better in that respect, as long as you force the synchronization from the CPU interface back to the redistributor via PHME and a DSB SY on each priority change. Which means what whatever you gain from not interrupting the other CPUs, you waste it by forcing synchronization system wide. > I'm also concerned that in a big.LITTLE system, you may see the big > CPUs > taking the interrupts all the time, which is nice for energy > efficiency. Yes, this is bound to happen. It means you cannot place interrupts on a small cluster unless you completely hotplug the big cores off, thanks to the "more than one means all" nonsense. And since these patches seem to also break hotplug, that's... fun. M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel