From: Ingo Molnar <mingo@elte.hu>
To: Don Zickus <dzickus@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
gorcunov@gmail.com, aris@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] [RFC] nmi_watchdog: config option to enable new nmi_watchdog
Date: Fri, 29 Jan 2010 09:12:27 +0100 [thread overview]
Message-ID: <20100129081227.GK14636@elte.hu> (raw)
In-Reply-To: <20100128154448.GV4472@redhat.com>
* Don Zickus <dzickus@redhat.com> wrote:
> On Thu, Jan 28, 2010 at 03:54:54PM +0100, Peter Zijlstra wrote:
> > On Wed, 2010-01-27 at 15:03 -0500, Don Zickus wrote:
> > > These are the bits that enable the new nmi_watchdog and safely isolate the
> > > old nmi_watchdog. Only one or the other can run, not both at the same
> > > time.
> >
> > perf disables the lapic watchdog when it wants the pmu, so there
> > shouldn't be a problem having both built in.
>
> Yes it does disable but does not prevent nmi_watchdog_tick from running nor
> the /proc interface from being loaded. So perhaps my description isn't very
> good. The idea with the new watchdog was to re-use some of the bits of the
> old one, but having them both compiled in seemed to stomp on each other.
> That is what I was trying to prevent.
>
> I can certainly change the behaviour, just makes the code a little more
> messy I think.
I think that's a good idea - and i think we want to be bold and just have the
new code run seemlessly. (and fix bugs, if any.)
In fact we want to be even bolder: how about enabling the NMI watchdog by
default again?
The problem with the old one was its fragility - but now if we have a PMU
driver active and perf events enabled we might as well use your brand new NMI
watchdog code as a testing facility as well: if there's _any_ problem with
NMIs then regular 'perf' use would trigger it too - except that not all people
run perf while an always-enabled NMI watchdog would.
And it would detect hard hangs too.
What do you think?
Ingo
next prev parent reply other threads:[~2010-01-29 8:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-27 20:03 [PATCH 0/3] [RFC] new nmi_watchdog using perf events Don Zickus
2010-01-27 20:03 ` [PATCH 1/3] [RFC][x86] move notify_die from nmi.c to traps.c Don Zickus
2010-01-28 15:10 ` Cyrill Gorcunov
2010-01-28 15:46 ` Don Zickus
2010-02-02 17:59 ` Cyrill Gorcunov
2010-02-02 18:27 ` Don Zickus
2010-02-02 18:44 ` Cyrill Gorcunov
2010-01-27 20:03 ` [PATCH 2/3] [RFC] nmi_watchdog: new implementation using perf events Don Zickus
2010-01-27 20:03 ` [PATCH 3/3] [RFC] nmi_watchdog: config option to enable new nmi_watchdog Don Zickus
2010-01-28 14:54 ` Peter Zijlstra
2010-01-28 15:44 ` Don Zickus
2010-01-29 8:12 ` Ingo Molnar [this message]
2010-02-01 18:52 ` Don Zickus
2010-02-02 7:29 ` Ingo Molnar
2010-02-02 16:42 ` 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=20100129081227.GK14636@elte.hu \
--to=mingo@elte.hu \
--cc=aris@redhat.com \
--cc=dzickus@redhat.com \
--cc=gorcunov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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
Powered by JetHome