lkml.org 
[lkml]   [2010]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2010-01-13 17:25    [W:0.089 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site