From: Don Zickus <dzickus@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: peterz@infradead.org, gorcunov@gmail.com, aris@redhat.com,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 3/3 v2] nmi_watchdog: config option to enable new nmi_watchdog
Date: Mon, 8 Feb 2010 09:58:13 -0500 [thread overview]
Message-ID: <20100208145813.GW3062@redhat.com> (raw)
In-Reply-To: <20100208071954.GA24721@elte.hu>
On Mon, Feb 08, 2010 at 08:19:54AM +0100, Ingo Molnar wrote:
>
> * Don Zickus <dzickus@redhat.com> wrote:
>
> > +config NMI_WATCHDOG
> > + bool "Detect Hard Lockups with an NMI Watchdog"
> > + depends on DEBUG_KERNEL && PERF_EVENTS
> > + default y
> > + help
> > + Say Y here to enable the kernel to use the NMI as a watchdog
> > + to detect hard lockups. This is useful when a cpu hangs for no
> > + reason but can still respond to NMIs. A backtrace is displayed
> > + for reviewing and reporting.
> > +
> > + The overhead should be minimal, just an extra NMI every few
> > + seconds.
>
> Thought for later patches: I think an architecture should be able to express
> via a Kconfig switch that it actually _has_ NMI events. There's architectures
> which dont have a PMU driver and only have software events. There's also
> architectures that have a PMU driver but no NMIs.
>
> Something like ARCH_HAS_NMI_PERF_EVENTS?
I guess I assumed the perf event subsystem would take care of that which
is why I made the config option dependent on PERF_EVENTS. I am open to
suggestions on enhance it.
>
> Also, i havent checked, but what is the practical effect of the new generic
> watchdog on x86 CPUs that does not have a native PMU driver yet - such as
> P4s?
I believe the call to perf_event_create_kernel_counter would fail, which
then prevents the cpu from coming online. Probably not the smartest thing
to do. I was looking at adding code to fall back to trying PERF_TYPE_SOFTWARE.
Let me dig up a P4 box and see what happens.
>
> Anyway, i'll create a tip:perf/nmi topic branch for these patches, it
> certainly looks like a useful generalization and a new architecture that has
> perf could easily enable it, without having to write its own NMI watchdog
> implementation. It's also useful for any new watchdog features that people
> might want to add. Plus it makes the x86 PMU code cleaner in the long run as
> well.
Agreed.
Cheers,
Don
next prev parent reply other threads:[~2010-02-08 14:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-06 2:47 [PATCH 0/3 v2] new nmi_watchdog using perf events Don Zickus
2010-02-06 2:47 ` [PATCH 1/3 v2] [x86] move notify_die from nmi.c to traps.c Don Zickus
2010-02-08 8:51 ` [tip:perf/nmi] x86: Move " tip-bot for Don Zickus
2010-02-06 2:47 ` [PATCH 2/3 v2] nmi_watchdog: new implementation using perf events Don Zickus
2010-02-08 8:51 ` [tip:perf/nmi] nmi_watchdog: Add new, generic implementation, " tip-bot for Don Zickus
2010-02-06 2:47 ` [PATCH 3/3 v2] nmi_watchdog: config option to enable new nmi_watchdog Don Zickus
2010-02-08 7:19 ` Ingo Molnar
2010-02-08 9:39 ` Cyrill Gorcunov
2010-02-08 14:58 ` Don Zickus [this message]
2010-02-08 8:52 ` [tip:perf/nmi] nmi_watchdog: Config " tip-bot for Don Zickus
2010-02-09 10:51 ` [tip:perf/nmi] nmi_watchdog: Only enable on x86 for now tip-bot for Ingo Molnar
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=20100208145813.GW3062@redhat.com \
--to=dzickus@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aris@redhat.com \
--cc=gorcunov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.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