Messages in this thread | | | Date | Wed, 13 Jan 2010 11:23:03 -0500 | From | Don Zickus <> | Subject | Re: introduce NMI_AUTO as nmi_watchdog option |
| |
On Wed, Jan 13, 2010 at 10:32:40AM +0100, Ingo Molnar wrote: > > After looking through the code I just had some questions, perhaps you have > > thought about this longer than me, what to do with the reservation code > > (just remove it I assume and let perf_events _be_ the only code that > > handles perf events) and what to do with some of the cpu quirks as noted in > > perfctr-watchdog.c (notable some of the Intel errata for the Core chipsets). > > Given the amount of quirks in the perctr code it might make sense to shape > this as a new feature initially: introduce a new NMI watchdog that is perf > based and has a different codebase. > > Then, once it's capable enough and has been in circulation long enough we can > simply drop the old NMI watchdog. (without users noticing anything [modulo > bugs]) > > v1 should concentrate on x86 CPUs that are supported by perf currently. Note, > it _might_ make sense to do it via a new kernel/nmi_watchdog.c file - other > architectures have NMI concepts as well, such as Sparc64. A further idea would > be to maybe even merge it with the softlockup code in kernel/softlockup.c - so > that we dont have two sets of apis like touch_nmi_watchdog and > touch_softlockup_watchdog.
Ok, interesting. Right now I am working on making sure I know how to register something with the perf event framework (from kernel space). Once I can do that, I'll expand it outward and see where it goes. :-)
> > So there's a wide spectrum of possibilities - the important thing is to start > small :-)
I see. Thanks.
Cheers, Don
| |