[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160531191827.GA4574@x>
Date: Tue, 31 May 2016 12:18:27 -0700
From: Josh Triplett <josh@...htriplett.org>
To: Daniel Bristot de Oliveira <bristot@...hat.com>
Cc: linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Steven Rostedt <rostedt@...dmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Lai Jiangshan <jiangshanlai@...il.com>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
"Luis Claudio R. Goncalves" <lgoncalv@...hat.com>
Subject: Re: [RFC PATCH 1/2] rcu: sysctl: Panic on RCU Stall
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@...htriplett.org>
Powered by blists - more mailing lists