Re: [tip:perf/urgent] perf, x86: Catch spurious interrupts after disabling counters

[Robert Richter <robert.richter@amd.com>]

On 29.09.10 15:42:26, Stephane Eranian wrote:
> On Wed, Sep 29, 2010 at 8:12 PM, Don Zickus <dzickus@redhat.com> wrote:
> > I think you missed Stephane's point.  Say for example, kgdb is being used
> > while we are doing stuff with the perf counter (and say kgdb's handler is
> > a lower priority than perf; which isn't true I know, but let's say):
> >
> Yes, exactly my point. The reality is you cannot afford to have false positive
> because you may starve another subsystem from an important notification.

As soon as you stop executing the chain, there are chances to miss an
nmi for other parts of the system. Where is no way to avoid this. So
your argument above is valid also for regular perf nmis and not only
for catched-spurious or back-to-back nmis.

> > Now I sent a patch last week that can prevent that extra NMI from being
> > generated at the cost of another rdmsrl in the non-pmu_stop cases (which I
> > will attach below again, obviously P4 would need something similar too).

A rdmsrl() does not help, it only causes overhead. There is no bit to
detect if a counter overflowed and triggered the interrupt, you only
know the counter value is greater zero or not.

We should take care the discussion becomes not academical and do not
start to overengineer something. I always can imagine some really rare
corner cases in which we may loss an nmi. This is because hardware is
not built for it. But in 99% or so of the cases we get all nmis,
instead of before where all nmis were eaten by the profiler.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center