All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>,
	aris@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: introduce NMI_AUTO as nmi_watchdog option
Date: Wed, 13 Jan 2010 11:23:03 -0500	[thread overview]
Message-ID: <20100113162303.GW24885@redhat.com> (raw)
In-Reply-To: <20100113093240.GC6739@elte.hu>

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

      parent reply	other threads:[~2010-01-13 16:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-11 19:16 introduce NMI_AUTO as nmi_watchdog option Don Zickus
2010-01-11 20:27 ` Cyrill Gorcunov
2010-01-11 20:33   ` Don Zickus
2010-01-11 20:51     ` Cyrill Gorcunov
2010-01-13  9:32     ` Ingo Molnar
2010-01-13 13:13       ` Peter Zijlstra
2010-01-13 16:25         ` Don Zickus
2010-01-13 16:42           ` Peter Zijlstra
2010-01-13 16:35         ` Ingo Molnar
2010-01-13 16:23       ` Don Zickus [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100113162303.GW24885@redhat.com \
    --to=dzickus@redhat.com \
    --cc=aris@redhat.com \
    --cc=gorcunov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.