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 99673C5519F for ; Fri, 27 Nov 2020 19:43:54 +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 205E224137 for ; Fri, 27 Nov 2020 19:43:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="aJspxQYN"; 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 205E224137 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-mediatek-bounces+linux-mediatek=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=2CPdH24sD3H2uV40DX4vj4ZrRks9nNduSX/4g9z/g5k=; b=aJspxQYNH9VKhl6EnS0qTCY/V kmCecRQWZYt1BHllCYmdOPyPM087/Onm4M9YrYGiYYyEKfG+LnIoMlDGYRHYwoBzi9iMpFI5rvqs2 ndziMgUtD9gCHVtIzPhtnChajAQ8Kh7n2njn3rooMT5ZBvCUGRU1tg6lFTv/reniIbQtB9GYyYlPP 72giE8DKMnU2UK4FkGdUDCfpwklKnzPvQ2FGfLOyky2j4nmTnmCodC/vUqSBgLQZbnmBPzoSxkoIw qVyhibLVOOcfBQ/liMKZrzbzvyks+oxDb8gnDGsGg/Hfd2rCaQJ1//snau7qwTuWIcUjh16bviO0I dnnOtubyw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kijek-0005k8-MO; Fri, 27 Nov 2020 19:43:46 +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-mediatek@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-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=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-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 4FB01C8301F for ; Sat, 28 Nov 2020 22:21:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 27D6822274 for ; Sat, 28 Nov 2020 22:21:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="yzOuRLDl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388340AbgK1Vtf (ORCPT ); Sat, 28 Nov 2020 16:49:35 -0500 Received: from mail.kernel.org ([198.145.29.99]:34460 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730498AbgK0TvY (ORCPT ); Fri, 27 Nov 2020 14:51:24 -0500 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 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 27 Nov 2020 19:43:40 +0000 From: Marc Zyngier To: Catalin Marinas Cc: Hanks Chen , Thomas Gleixner , Matthias Brugger , Russell King , Will Deacon , Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, CC Hwang , Kuohong Wang , Loda Chou 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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...