Re: [PATCH -v2] perf, x86: try to handle unknown nmis with running perfctrs

[Cyrill Gorcunov <gorcunov@gmail.com>]

On Mon, Aug 16, 2010 at 04:48:36PM +0200, Peter Zijlstra wrote:
...
> > There is another case if there are two subsequent back-to-back nmis
> > [3]. In this case we measure the time between the first and the
> > 2nd. The 2nd is detected as back-to-back because the first handled
> > more than one counter. The time between the 1st and the 2nd is used to
> > calculate a range for which we assume a back-to-back nmi. Now, the 3rd
> > nmi triggers, we measure again the time delta and compare it with the
> > first delta from which we know it was a back-to-back nmi. If the 3rd
> > nmi is within the range, it is also a back-to-back nmi and we drop it. 
> 
> I liked the one without funny timestamps in better, the whole timestamps
> thing just feels too fragile.
> 

Me too, the former Roberts patch (if I'm not missing something) looks good
to me.

>
> Relying on handled > 1 to arm the back-to-back filter seems doable.
> 

It's doable _but_ I think there is nothing we can do, there is no
way (at least I known of) to check if there is latched nmi from
perf counters. We only can assume that if there multiple counters
overflowed most probably the next unknown nmi has the same nature,
ie it came from perf. Yes, we can loose real unknown nmi in this
case but I think this is justified trade off. If an user need
a precise counting of unknown nmis he should not arm perf events
at all, if there an user with nmi button (guys where did you get this
magic buttuns? i need one ;) he better to not arm perf events too
otherwise he might have to click twice

(and of course we should keep in mind Andi's proposal but it
 is a next step I think).

> (Also, you didn't deal with the TSC going backwards..)
> 
	-- Cyrill