Re: introduce NMI_AUTO as nmi_watchdog option

[Peter Zijlstra <peterz@infradead.org>]

On Wed, 2010-01-13 at 11:25 -0500, Don Zickus wrote:
> On Wed, Jan 13, 2010 at 02:13:42PM +0100, Peter Zijlstra wrote:
> > On Wed, 2010-01-13 at 10:32 +0100, Ingo Molnar wrote:
> > > other architectures have NMI concepts as well, such as Sparc64. 
> > 
> > I think both sparc64 and ppc64 fake NMIs by playing games with hw IRQ
> > priorities and partial masks. But yes.
> > 
> > One interesting 'feature' for the perf-nmi interaction is creating an
> > idle scheduling class for counters, because as long as there is a
> > counter present you can use his NMIs to drive the watchdog, but as soon
> > as there are non left, you need to install one.
> 
> Interesting idea.  How can I guarantee the frequency of the NMI I want to
> piggyback off of?  A breakpoint that takes an hour to trigger may not be
> the best NMI to use?  Then again I am still trying to understand the perf
> event code a little better.

You could play games with the period, we can handle getting more NMIs
than are needed. This is how we implement a period larger than the
physical counter for example.

But yeah, its a tricky game since a tight loop might never generate the
event we're counting.. we could limit this to things like
cycles/ins/bus-cycles etc.. those will always tick.

Anyway, its all an optimization, the simple/first implementation would
simply install a kernel cpu perf counter and hook the overflow handler.