[RCU]stallwarn.txt

2013/08/14kernel_documentimport
FILE: kernel-*/Documentation/RCU/stallwarn.txt
kernel-3.2.26, 3.2.8

Using RCU's CPU Stall Detector

The rcu_cpu_stall_suppress module parameter enables RCU's CPU stall detector, which detects conditions that unduly delay RCU grace periods.
rcu_cpu_stall_suppressモジュールパラメータは、RCUのCPUストール検出が可能になります。
ここでいうストールとは、過度にRCUの猶予期間が遅延する状態を検出することです。

This module parameter enables CPU stall detection by default, but may be overridden via boot-time parameter or at runtime via sysfs.
このmodule parameterは、デフォルトでCPUストール検出を有効にしますが、boot時のparmeterもしくはsysfs経由でruntimeに上書きすることができます。

The stall detector's idea of what constitutes "unduly delayed" is controlled by a set of kernel configuration variables and cpp macros
"過度な遅延"を構成するストール検出器のアイデアは、カーネルの設定変数とCPPマクロのセットによって制御されます。
  • CONFIG_RCU_CPU_STALL_TIMEOUT
    This kernel configuration parameter defines the period of time that RCU will wait from the beginning of a grace period until it issues an RCU CPU stall warning. This time period is normally ten seconds.
    このカーネル設定変数は、RCUが、猶予期間のはじめから、"RCU CPU stall"警告を発行するまでの待ち期間を定義します。この期間は、通常１０秒です。
  • RCU_SECONDS_TILL_STALL_RECHECK
    This macro defines the period of time that RCU will wait after issuing a stall warning until it issues another stall warning for the same stall.This time period is normally set to three times the check interval plus thirty seconds.
    このマクロは、RCUが"stall warning"を発行した後、別要因で同じstallのstall warningを発行するまでの期間を定義します。この期間は、通常チェック周期の３倍＋３０秒にセットされます。
  • RCU_STALL_RAT_DELAY
    The CPU stall detector tries to make the offending CPU print its own warnings, as this often gives better-quality stack traces.However, if the offending CPU does not detect its own stall in the number of jiffies specified by RCU_STALL_RAT_DELAY, then some other CPU will complain.This delay is normally set to two jiffies.
    CPU stall検出器は、よりよい品質のスタックトレースを与えるために、問題のCPUは独自の警告を出力しようとします。しかし、問題のCPUが RCU_STALL_RAT_DELAYで与えられるjiffies単位の間に、自身のストールを検出できない場合、他のCPUが出力します。この遅延は、通常 2jiffiesになります。
When a CPU detects that it is stalling, it will print a message similar to the following
CPUがストールを検出するとき、以下のようなメッセージを出力します。
INFO: rcu_sched_state detected stall on CPU 5 (t=2500 jiffies)
This message indicates that CPU 5 detected that it was causing a stall, and that the stall was affecting RCU-sched.
このメッセージは、CPU5が、ストールの原因であることを検出したことを示しています。そして、ストールは、RCH-schedに影響を及ぼすことを示しています。
This message will normally be followed by a stack dump of the offending CPU.
このメッセージは、通常、問題のCPUのスタックダンプが続きます。
On TREE_RCU kernel builds, RCU and RCU-sched are implemented by the same underlying mechanism,while on TREE_PREEMPT_RCU kernel builds, RCU is instead implemented by rcu_preempt_state.
TREE_RCU kernel buildに於いて、RCUとRCU-scedは同じ基本的なメカニズムで実装されています。TREE_PREEMPT_RCU kernel buildに於いては、RCUは代わりに、rcu_preempt_stateによって実装されます。
On the other hand, if the offending CPU fails to print out a stall-warning message quickly enough,some other CPU will print a message similar to the following
言い換えれば、問題のあるCPUがstall-警告メッセージを十分に早く出力することに失敗するならば、他のCPUが以下のように出力する：
INFO: rcu_bh_state detected stalls on CPUs/tasks: { 3 5 } (detected by 2, 2502 jiffies)
This message indicates that CPU 2 detected that CPUs 3 and 5 were both causing stalls,and that the stall was affecting RCU-bh.
このメッセージは、CPU2が、CPU3と5の両方がstall要因であることを検出したこと、および、RCH-bhへ影響を与えたことを示しています。

This message will normally be followed by stack dumps for each CPU.
このメッセージは、通常、各CPUのスタックダンプが続きます。

Please note that TREE_PREEMPT_RCU builds can be stalled by tasks as well as by CPUs,and that the tasks will be indicated by PID, for example, "P3421".
TREE_PREEMPT_RCU buildでは、CPUのようにタスクによってstallすることができることに注意してください。また、タスクはPIDによって示されます。例えば"P3421"といった具合です。

It is even possible for a rcu_preempt_state stall to be caused by both CPUs -and- tasks,in which case the offending CPUs and tasks will all be called out in the list.
rcu_preempt_stateのstallも、CPUやタスクを起因として起こりえます。この場合、問題のCPUとタスクは、すべてのリストで呼び出されます。

Finally, if the grace period ends just as the stall warning starts printing, there will be a spurious stall-warning message
最後に、stall警告が出力されはじめるのと同時に、猶予期間が終わったならば、誤ったstall警告メッセージがあるだろう。
INFO: rcu_bh_state detected stalls on CPUs/tasks: { } (detected by 4, 2502 jiffies)
This is rare, but does happen from time to time in real life.
これはレアだけれども、実生活に於いて随時現れます。

So your kernel printed an RCU CPU stall warning.The next question is "What caused it?" The following problems can result in RCU CPU stall warnings
なので、kernelがRCU CPU stall warningを出力します。次の質問は、"なにがそれを引き起こしたか？"です。以下の問題がRCU CPU stall warningになることがあります。
  • A CPU looping in an RCU read-side critical section.\CPUが、RCUの読み込み側クリティカルセクション内をループしている。
  • A CPU looping with interrupts disabled. This condition can result in RCU-sched and RCU-bh stalls.\CPUが、割り込み禁止状態でループしている。この状態は、RCU-sched stall と RCU-bh stallにつながる。
  • A CPU looping with preemption disabled. This condition can result in RCU-sched stalls and, if ksoftirqd is in use, RCU-bh stalls.\CPUが、preemption無効でループしている。この状態はRCU-sched stallになる。そして、ksoftirqdを使用しているならば、RCU-bh stallになる。
  • A CPU looping with bottom halves disabled. This condition can result in RCU-sched and RCU-bh stalls.\CPUが、bottom halfを無効にしてループしている。この状態は、RCU-sched stall と RCU-bh stallにつながる。
  • For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel without invoking schedule().\CONFIG_PREEMPTを無効にしたカーネルに於いて、kernel内で、schedule()関数を呼び出していないところをループしている。
  • A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might happen to preempt a low-priority task in the middle of an RCU read-side critical section.CONFIG_PREEMPTが有効になったkernelに於いて、RCU読み出し側のクリティカルセクションの途中で、優先度の低いタスクをpreemptするために起こる可能性があるCPU-boundリアルタイムタスク。\※訳注※\この意味理解しないと。。。RealTime TaskがRCU critical sectionを強奪できる? Dispatch禁止も効かない？？[color:#808000:This is especially damaging if that low-priority task is not permitted to run on any other CPU,in which case the next RCU grace period can never complete,which will eventually cause the system to run out of memory and hang.While the system is in the process of running itself out of you, memory might see stall-warning messages.\これは、優先度の低いタスクが他のCPUで実行することが許可されいない場合、特にダメージを受ける。その場合には、次のRCU猶予期間は、最終的には、システムのメモリが不足してハングアップする原因となり、これが完了できません。-A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that is running at a higher priority than the RCU softirq threads.This will prevent RCU callbacks from ever being invoked, and in a CONFIG_TREE_PREEMPT_RCU kernel will further prevent RCU grace periods from ever completing.Either way, the system will eventually run out of memory and hang.In the CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning messages.\CONFIG_PREEMPTが有効になったkernelに於いて、RCU softirq threadよりも高い優先度で実行しているCPU-boundリアルタイムタスク。
  • A bug in the RCU implementation.\RCU実装の不具合
  • 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.\ハードウェア不良。これは非常に考えにくいが、実生活に於いて少なくとも一度は発生しました。CPUが応答しなくなって、実行中のシステムで失敗したが、即時のクラッシュをひきおこしていない。これは、最終的にはCPUが失敗したという認識をリードし、RCP CPUストールの警告シリーズとなる。
The RCU, RCU-sched, and RCU-bh implementations have CPU stall warning.
SRCU does not have its own CPU stall warnings,but its calls to synchronize_sched() will result in RCU-sched detectingRCU-sched-related CPU stalls.
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.
If you have a series of stall warnings from a single extended stall, comparing the stack traces can often help determine where the stallis occurring, which will usually be in the function nearest the top of that portion of the stack which remains the same from trace to trace.
If you can reliably trigger the stall, ftrace can be quite helpful.


RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE.

関連記事