[PATCH] powerpc/booke64: Configurable lazy interrupt disabling

Stuart Yoder b08248 at gmail.com
Fri Jan 20 06:29:38 EST 2012


On Thu, Jan 19, 2012 at 1:21 PM, Stuart Yoder <b08248 at gmail.com> wrote:
> On Wed, Jan 18, 2012 at 3:10 PM, Benjamin Herrenschmidt
> <benh at kernel.crashing.org> wrote:
>> On Wed, 2012-01-18 at 16:35 +0200, Laurentiu Tudor wrote:
>>> This patch adds a menuconfig option that allows controlling
>>> the lazy interrupt disabling feature implemented by this
>>> commit:
>>>
>>> commit d04c56f73c30a5e593202ecfcf25ed43d42363a2
>>> Author: Paul Mackerras
>>> Date:   Wed Oct 4 16:47:49 2006 +1000
>>>
>>>     [POWERPC] Lazy interrupt disabling for 64-bit machines
>>>
>>> The code in 'powerpc/include/asm/hw_irq.h' was rearranged and
>>> cleaned-up a bit in order to reduce the number of needed #ifdef's.
>>
>> It's still nasty. Do you have numbers showing that it's worth disabling
>> on BookE ?
>
> It's not just about bare metal performance-- some platforms such as
> the Freescale
> Topaz hypervisor don't provide legacy IACK type interrupt
> acknowledgment, and expect
> the guest to support the external proxy mechanism.
>
> With Topaz, interrupts go directly to guests and we don't want to require a
> trap/hcall to do an IACK, as that adds potentially thousands of cycles of
> latency to every interrupt.
>
> As you know, with external proxy interrupts are acknowledged by the
> hardware and it becomes problematic to replay the interrupt in
> the context of lazy EE when interrupts are re-enabled.   The interrupt
> will not fire again when you enable EE.
>
> That is currently the issue, as we can't run the 64-bit kernel on Topaz.
> Our option are:
>  1) to provide an option to disable lazy EE
>  2) do some kind of hack to replay interrupts with lazy EE
>  3) change Topaz to support legacy IACK, but this gets ugly for
>      various reasons.
>
> Providing a config option to disable lazy EE seemed to be a good
> approach.

Also, Scott had posted an approach to do option #2 a while back,
but as I  recall there was some negative feedback about this.  See:
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-August/092103.html>

Stuart


More information about the Linuxppc-dev mailing list