Re: [PATCH] powerpc/booke64: Configurable lazy interrupt disabling

[Scott Wood <scottwood@freescale.com>]

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).

-Scott