From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
mingo@elte.hu, "David S. Miller" <davem@davemloft.net>,
"Paul Mackerras" <paulus@samba.org>,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
eranian@gmail.com, perfmon2-devel@lists.sf.net
Subject: Re: [BUG] perf_events: NMI watchdog event cannot be throttled
Date: Thu, 19 Aug 2010 13:05:16 +0200 [thread overview]
Message-ID: <1282215916.1926.4696.camel@laptop> (raw)
In-Reply-To: <AANLkTimdnYjDsr4GYgw=M74hH0hzyRDeb7WqfiE8-BT1@mail.gmail.com>
On Wed, 2010-08-18 at 22:26 +0200, Stephane Eranian wrote:
> Hi,
>
> I ran into some issue with the NMI watchdog not firing in a deadlock
> situation. After some debugging I found the source of the problem.
>
> The NMI watchdog is currently subject, like any other events, to interrupt
> throttling. The heart of the problem is that if you are deadlocked on a CPU
> with interrupts masked, the timer interrupt won't fire, therefore the
> hwc->interrupts
> field won't be reset. Then, depending on the max sampling rate, you
> could eventually
> fail the max interrupt rate test in __pfm_overflow_handler() and
> perf_events would
> throttle, i.e., stop, the NMI watchdog event before the 5s delay to panic.
> Thus, you would never get the panic. I ran into this problem myself.
>
> This is a serious issue because perf_events must ensure the watchdog can
> always fire, regardless of the interrupt masking situation.
>
> Look like one way of solving the problem would be to mark the NMI watchdog
> event as immune to throttling. The event being internal to the kernel we could
> trust the event setup from perf_event_create_kernel_counter().
Something like so?
---
kernel/watchdog.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 613bc1f..e0fe6e4 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -206,6 +206,9 @@ void watchdog_overflow_callback(struct perf_event *event, int nmi,
struct perf_sample_data *data,
struct pt_regs *regs)
{
+ /* Ensure the watchdog never gets throttled. */
+ event->hw.interrupts = 0;
+
if (__get_cpu_var(watchdog_nmi_touch) == true) {
__get_cpu_var(watchdog_nmi_touch) = false;
return;
next prev parent reply other threads:[~2010-08-19 11:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-18 20:26 Stephane Eranian
2010-08-19 11:05 ` Peter Zijlstra [this message]
2010-08-19 11:24 ` Stephane Eranian
2010-08-19 13:01 ` Stephane Eranian
2010-08-20 14:18 ` [tip:perf/urgent] watchdog: Don't throttle the watchdog tip-bot for Peter Zijlstra
2010-08-23 8:51 ` tip-bot for Peter Zijlstra
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=1282215916.1926.4696.camel@laptop \
--to=peterz@infradead.org \
--cc=davem@davemloft.net \
--cc=eranian@gmail.com \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=perfmon2-devel@lists.sf.net \
/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