From: Josh Triplett <josh@joshtriplett.org>
To: Daniel Bristot de Oliveira <bristot@redhat.com>
Cc: linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
"Luis Claudio R. Goncalves" <lgoncalv@redhat.com>
Subject: Re: [RFC PATCH 1/2] rcu: sysctl: Panic on RCU Stall
Date: Tue, 31 May 2016 12:23:26 -0700 [thread overview]
Message-ID: <20160531192325.GA4851@x> (raw)
In-Reply-To: <20160531191827.GA4574@x>
On Tue, May 31, 2016 at 12:18:27PM -0700, Josh Triplett wrote:
> On Tue, May 31, 2016 at 04:07:32PM -0300, Daniel Bristot de Oliveira wrote:
> > It is not always easy to define the cause of an RCU stall just by
> > analysing the RCU stall messages, mainly when the problem is caused
> > by the indirect starvation of rcu threads. For example, when preempt_rcu
> > is not awakened due to the starvation of a timer softirq.
> >
> > We have been hard coding panic() in the RCU stall functions for
> > some time while testing the kernel-rt. But this is not possible in
> > some scenarios, like when supporting customers.
> >
> > This patch implements the sysctl kerner.panic_on_rcu_stall. If
> > set to 1, the system will panic() when an RCU stall takes place,
> > enabling the capture of a vmcore. The vmcore provides a way to analyze
> > all kernel/tasks states, helping out to point to the culprit and the
> > solution for the stall.
> >
> > The kerner.panic_on_rcu_stall sysctl is disabled by default.
>
> s/kerner/kernel/ (here and in the previous paragraph).
>
> Also, even though it's only two lines, please consider creating a static
> function wrapping the if and panic, to avoid duplication.
>
> With those changes,
> Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Sorry, realized something else a moment after sending: I don't think
this will build if you use the tiny RCU implementation. That
implementation *does* support tracing, and if you enable tracing,
you'll have CONFIG_RCU_STALL_COMMON=y, but you won't build tree.c where
the variable definition lives. So, the sysctl code will reference a
variable that doesn't exist.
- Josh Triplett
next prev parent reply other threads:[~2016-05-31 19:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-31 19:07 [RFC PATCH 0/2] sysctl: Panic on RCU stall and schedule while atomic Daniel Bristot de Oliveira
2016-05-31 19:07 ` [RFC PATCH 1/2] rcu: sysctl: Panic on RCU Stall Daniel Bristot de Oliveira
2016-05-31 19:18 ` Josh Triplett
2016-05-31 19:23 ` Josh Triplett [this message]
2016-05-31 22:49 ` Daniel Bristot de Oliveira
2016-06-01 2:34 ` Paul E. McKenney
2016-05-31 19:07 ` [RFC PATCH 2/2] sched: sysctl: Panic on scheduling while atomic Daniel Bristot de Oliveira
2016-05-31 19:20 ` Josh Triplett
2016-06-01 9:45 ` Peter Zijlstra
2016-06-01 13:37 ` Daniel Bristot de Oliveira
2016-05-31 19:27 ` [RFC PATCH 0/2] sysctl: Panic on RCU stall and schedule " Christian Borntraeger
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=20160531192325.GA4851@x \
--to=josh@joshtriplett.org \
--cc=acme@kernel.org \
--cc=bristot@redhat.com \
--cc=corbet@lwn.net \
--cc=jiangshanlai@gmail.com \
--cc=lgoncalv@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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