Re: [PATCH] perf, nmi: fix unknown NMI warning

[Peter Zijlstra <peterz@infradead.org>]

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.