[PATCH] powerpc/booke64: Configurable lazy interrupt disabling
scottwood at freescale.com
Tue Jan 31 10:13:07 EST 2012
On 01/30/2012 04:15 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2012-01-30 at 15:47 -0600, Scott Wood wrote:
>> Only the first one will happen in a context where we want to store. The
>> issue is if we get another higher priority interrupt when we enable, and
>> that enables interrupts and we get the doorbell that wants to run the
>> saved irq. If we get priorities out of order we'll EOI the wrong interrupt.
> Hrm, ok, what about in handle_masked we just "save" it onto some kind of
> PACA local stack ? Then on enable, before actually turning EE back, we
> see if there's something there and we hit do_IRQ() if there is. Your
> get_irq() would preferrably pop things out of that little stack.
> Any hole in that scheme ?
If we never enable EE, there's no need for a stack -- we disable EE on
the first interrupt and can leave it in EPR. It's similar to my
original patch, but with the exception hack replaced with a call to
do_IRQ(). The quality of the regs you pass (if any) may suffer, which
is why I did the exception hack, but I can live with that if you can.
>> IIRC we now never enable interrupts while servicing one (are individual
>> handlers banned from doing this too?),
> No I think they still can.
OK. Another option could be to use the doorbell and store EPR
somewhere, but make sure if we get a real interrupt and there's a
pending interrupt stored, we clear it out and process both in proper
order. When the doorbell eventually fires it's a nop. Testing this
would require some effort, though. Better to stick with the simple
scheme where we never enable EE with a pending interrupt.
>>> However the main thing is that this significantly improves the quality
>>> of the samples obtained from performance interrupts which can now act as
>>> pseudo-NMI up to a certain point.
>> Which is compensation for the hardware not doing it right with a proper
>> critical interrupt or equivalent, but yeah, that's a benefit.
> Right, server has no concept really of critical interrupts.
Would be nice if the embedded version used critical, though (or could be
configured to do so).
More information about the Linuxppc-dev