Messages in this thread | | | Date | Sun, 16 Feb 2014 20:23:12 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH] perf, nmi: fix unknown NMI warning |
| |
On Sun, Feb 16, 2014 at 07:38:50PM +0100, Andi Kleen wrote: > > This reminds me of the late-ack stuff; > > > > The way I understand interrupts to work is that when you raise the > > interrupt it gets latched, when you ACK you drop the latch. Then when it > > gets re-raised while its still in progress, it gets latched again and > > the irq-enable at the end of the running handler will get it to trigger > > again. > > > > So by late-ACK-ing the PMI we can miss PMIs that happen between enabling > > the PMU and ACKing the PMI. > > My understanding is that all these things are different latches/states, like > semaphores in a queue. pending-state, not-acked-state, interrupts disabled > state. There's also some delay in propagating between the states, which > was the reason we needed the late-ack in the first place. > > Your argument relies on (1) and (2) being the same physical latch, > right?
Indeed so; if they're separate states then things are fine. Are any of these details documented someplace?
> The late-ack method was originally blessed by the hardware architects. > > Also I don't think it would matter in any case because: > > > > > We should either re-check the overflow mask after the ACK or do the ACK > > while the PMU is disabled. > > For PMU that would be just a back-to-back PMI. We filter those > out anyways.
In this case the latter NMI will actually have an overflow state to process so it's not a spurious NMI.
> And if we're in a state that PMIs get re-raised quickly, we should either > regulate the period down or start throttling.
It could be a different counter; where both run at 'normal' periods but just near miss each other by accident.
And sure; its all stats and over all it shouldn't matter that much, but we should still try and do our best regardless.
| |