>I have another question for UP APIC NMI: As I reported some time ago,
>if performance counters overflow when LVTPC has 'disabled' bit set,
>NMI is lost forever. This causes problems with VMware - it has to
>disable NMI deliveries during CR3 (memory mapping) switching, and if
>performance counter overflows at that time, you'll not receive another
>NMI for couple of days on K7 (4.1 * 65536 seconds on fully loaded 1GHz
>Athlon. And 410 * 65536 seconds on idle Athlon)...
How long do you need to keep NMIs blocked?
The watchdog (re-)initialises the perfctr to a negative value, but
after overflow the counter will read as positive. (You'll have to
use rdpmc() and sign-extend the low bits of the high word.)
So if, after your critical section, the counter reads as positive
you know that you missed an NMI. In that case, just write the restart
value to the counter.
Alternatively, if you block the NMI watchdog for a long time, say a
couple of thousand cycles or more, you can unconditionally restart it.
(I had a theory about inspecting the APIC_LVTPC "Delivery Status"
field, but unfortunately it doesn't seem to get set if a counter
overflowed while LVTPC was masked. Perhaps it's because NMIs are
edge-triggered.)
>So it came to my mind - why (on K7 we easy can, as counter has 48 bits)
>we do not reload NMI watchdog in each timer interrupt with 5sec timeout,
>and if we receive even one NMI, we are locked up? It should increase
>performance, as we'll do same number of MSR writes anyway (100/s), but
>we will not receive any NMI during normal operation, so we save time
>spent in processing this. Or do I miss something?
The 100 NMI/s rate was just to match the original IO-APIC driven watchdog;
it's certainly not a design goal to have the rate this high. In fact,
we'll probably reduce it to 1Hz soon. (I'm running it in that mode now.)
/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/