> What would happen with a 'stuck' event in the new scheme? The usual reason events are stuck is that perf programs a too low period in frequency mode after fork.
We have two safety mechanisms: - The perf overflow code checks against the max number of overflows per second, and forces a lower period if needed. - The NMI duration limiter checks the total length of NMI With the low period problem it will bump into the first limit. The second limit also makes sure not too much CPU time is lost. It wouldn't handle a case where the interrupt handler gets re-issued without overflowing, but I don't think that can really happen (except for the check point case, which is also covered) > > In principle the sequence should work on other CPUs too, but > > since I only tested on Skylake it is only enabled there. > > I would very much like a reduction of the ack states. You introduced the > late thing, which should also work for everyone, and now you introduce > yet another variant. Ingo suggested to do it this way. Originally I thought it wasn't needed, but I think now that late-ack made some of the races that eventually caused Skylake LBR to fall over worse. So in hindsight it was a good idea to not use it everywhere. > I would very much prefer a single ack scheme if at all possible. Could enable it everywhere, but then users would need to test it on most types of CPUs, as I can't. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/