Re: [PATCH 1/4] x86, perf: Use a new PMU ack sequence on Skylake

[Andi Kleen <ak@linux.intel.com>]

> 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

-- 
ak@linux.intel.com -- Speaking for myself only