From: Ingo Molnar <mingo@elte.hu>
To: Don Zickus <dzickus@redhat.com>
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 10:32:40 +0100 [thread overview]
Message-ID: <20100113093240.GC6739@elte.hu> (raw)
In-Reply-To: <20100111203356.GU24885@redhat.com>
* Don Zickus <dzickus@redhat.com> wrote:
> On Mon, Jan 11, 2010 at 11:27:29PM +0300, Cyrill Gorcunov wrote:
> > On Mon, Jan 11, 2010 at 02:16:33PM -0500, Don Zickus wrote:
> > > Hi Ingo,
> > >
> > ...
> > > I was going to jump in and try to do this work. I wanted to make sure
> > > what you were looking for here. When you say convert nmi watchdog to perf
> > > events, I assume you mean merging over the bits of perfctr-watchdog.c to
> > > perf_events.c, modify nmi.c to just register as a normal perf event and
> > > probably cleanup the oprofile stuff to match, correct?
> > >
> > > Cheers,
> > > Don
> > >
> >
> > As far as I know -- converting perfctr-watchdog.c to into perfevents
> > style would be quite a desirable feature. But I still didn't manage to
> > find time for this task :( If you're interested to start this work
> > -- that would be just great!
>
> 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.
So there's a wide spectrum of possibilities - the important thing is to start
small :-)
Ingo
next prev parent reply other threads:[~2010-01-13 9:32 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 [this message]
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
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=20100113093240.GC6739@elte.hu \
--to=mingo@elte.hu \
--cc=aris@redhat.com \
--cc=dzickus@redhat.com \
--cc=gorcunov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox