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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
