From: "Paul E. McKenney" <paulmck@kernel.org>
To: rcu@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
rostedt@goodmis.org, "Paul E. McKenney" <paulmck@kernel.org>
Subject: [PATCH rcu 07/15] doc: Update stallwarn.rst
Date: Wed, 4 Jan 2023 16:09:47 -0800 [thread overview]
Message-ID: <20230105000955.1767218-7-paulmck@kernel.org> (raw)
In-Reply-To: <20230105000945.GA1767128@paulmck-ThinkPad-P17-Gen-1>
This commit updates stallwarn.rst to reflect RCU additions and changes
over the past few years.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
---
Documentation/RCU/stallwarn.rst | 43 +++++++++++++++++++--------------
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/Documentation/RCU/stallwarn.rst b/Documentation/RCU/stallwarn.rst
index e38c587067fc8..dfa4db8c0931e 100644
--- a/Documentation/RCU/stallwarn.rst
+++ b/Documentation/RCU/stallwarn.rst
@@ -25,10 +25,10 @@ warnings:
- A CPU looping with bottom halves disabled.
-- For !CONFIG_PREEMPTION kernels, a CPU looping anywhere in the kernel
- without invoking schedule(). If the looping in the kernel is
- really expected and desirable behavior, you might need to add
- some calls to cond_resched().
+- For !CONFIG_PREEMPTION kernels, a CPU looping anywhere in the
+ kernel without potentially invoking schedule(). If the looping
+ in the kernel is really expected and desirable behavior, you
+ might need to add some calls to cond_resched().
- Booting Linux using a console connection that is too slow to
keep up with the boot-time console-message rate. For example,
@@ -108,16 +108,17 @@ warnings:
- A bug in the RCU implementation.
-- A hardware failure. This is quite unlikely, but has occurred
- at least once in real life. A CPU failed in a running system,
- becoming unresponsive, but not causing an immediate crash.
- This resulted in a series of RCU CPU stall warnings, eventually
- leading the realization that the CPU had failed.
+- A hardware failure. This is quite unlikely, but is not at all
+ uncommon in large datacenter. In one memorable case some decades
+ back, a CPU failed in a running system, becoming unresponsive,
+ but not causing an immediate crash. This resulted in a series
+ of RCU CPU stall warnings, eventually leading the realization
+ that the CPU had failed.
-The RCU, RCU-sched, and RCU-tasks implementations have CPU stall warning.
-Note that SRCU does *not* have CPU stall warnings. Please note that
-RCU only detects CPU stalls when there is a grace period in progress.
-No grace period, no CPU stall warnings.
+The RCU, RCU-sched, RCU-tasks, and RCU-tasks-trace implementations have
+CPU stall warning. Note that SRCU does *not* have CPU stall warnings.
+Please note that RCU only detects CPU stalls when there is a grace period
+in progress. No grace period, no CPU stall warnings.
To diagnose the cause of the stall, inspect the stack traces.
The offending function will usually be near the top of the stack.
@@ -205,16 +206,21 @@ RCU_STALL_RAT_DELAY
rcupdate.rcu_task_stall_timeout
-------------------------------
- This boot/sysfs parameter controls the RCU-tasks stall warning
- interval. A value of zero or less suppresses RCU-tasks stall
- warnings. A positive value sets the stall-warning interval
- in seconds. An RCU-tasks stall warning starts with the line:
+ This boot/sysfs parameter controls the RCU-tasks and
+ RCU-tasks-trace stall warning intervals. A value of zero or less
+ suppresses RCU-tasks stall warnings. A positive value sets the
+ stall-warning interval in seconds. An RCU-tasks stall warning
+ starts with the line:
INFO: rcu_tasks detected stalls on tasks:
And continues with the output of sched_show_task() for each
task stalling the current RCU-tasks grace period.
+ An RCU-tasks-trace stall warning starts (and continues) similarly:
+
+ INFO: rcu_tasks_trace detected stalls on tasks
+
Interpreting RCU's CPU Stall-Detector "Splats"
==============================================
@@ -248,7 +254,8 @@ dynticks counter, which will have an even-numbered value if the CPU
is in dyntick-idle mode and an odd-numbered value otherwise. The hex
number between the two "/"s is the value of the nesting, which will be
a small non-negative number if in the idle loop (as shown above) and a
-very large positive number otherwise.
+very large positive number otherwise. The number following the final
+"/" is the NMI nesting, which will be a small non-negative number.
The "softirq=" portion of the message tracks the number of RCU softirq
handlers that the stalled CPU has executed. The number before the "/"
--
2.31.1.189.g2e36527f23
next prev parent reply other threads:[~2023-01-05 0:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-05 0:09 [PATCH rcu 0/15] Documentation updates for v6.3 Paul E. McKenney
2023-01-05 0:09 ` [PATCH rcu 01/15] doc: Further updates to RCU's lockdep.rst Paul E. McKenney
2023-01-05 0:09 ` [PATCH rcu 02/15] doc: Update NMI-RCU.rst Paul E. McKenney
2023-01-05 0:09 ` [PATCH rcu 03/15] doc: Update rcubarrier.rst Paul E. McKenney
2023-01-05 0:09 ` [PATCH rcu 04/15] doc: Update rcu_dereference.rst Paul E. McKenney
2023-01-05 0:09 ` [PATCH rcu 05/15] doc: Update and wordsmith rculist_nulls.rst Paul E. McKenney
2023-01-05 0:09 ` [PATCH rcu 06/15] doc: Update rcu.rst Paul E. McKenney
2023-01-05 0:09 ` Paul E. McKenney [this message]
2023-01-05 0:09 ` [PATCH rcu 08/15] doc: Update torture.rst Paul E. McKenney
2023-01-05 0:09 ` [PATCH rcu 09/15] doc: Update UP.rst Paul E. McKenney
2023-01-05 0:09 ` [PATCH rcu 10/15] doc: Update rcu.rst URL to RCU publications Paul E. McKenney
2023-01-05 0:09 ` [PATCH rcu 11/15] doc: Update whatisRCU.rst Paul E. McKenney
2023-01-05 0:09 ` [PATCH rcu 12/15] doc: Document CONFIG_RCU_CPU_STALL_CPUTIME=y stall information Paul E. McKenney
2023-01-05 0:09 ` [PATCH rcu 13/15] docs/RCU/rcubarrier: Adjust 'Answer' parts of QQs as definition-lists Paul E. McKenney
2023-01-05 0:09 ` [PATCH rcu 14/15] docs/RCU/rcubarrier: Right-adjust line numbers in code snippets Paul E. McKenney
2023-01-05 0:09 ` [PATCH rcu 15/15] doc: Fix htmldocs build warnings of stallwarn.rst Paul E. McKenney
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=20230105000955.1767218-7-paulmck@kernel.org \
--to=paulmck@kernel.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rcu@vger.kernel.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