Re: [PATCH v1 1/3] irqchip/gic: enable irq target all

From: Marc Zyngier <maz@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	CC Hwang <cc.hwang@mediatek.com>,
	Loda Chou <loda.chou@mediatek.com>,
	Hanks Chen <hanks.chen@mediatek.com>,
	Kuohong Wang <kuohong.wang@mediatek.com>,
	Russell King <linux@armlinux.org.uk>,
	linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v1 1/3] irqchip/gic: enable irq target all
Date: Fri, 27 Nov 2020 19:43:40 +0000	[thread overview]
Message-ID: <dab968d8c7629c7aebc5e62770a9743d@kernel.org> (raw)
In-Reply-To: <20201127185610.GA30096@gaia>

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