RCU CPU STALL DETECTOR

关注

转载最新推荐文章于 2026-08-18 13:38:20 发布 8.9k 阅读 AI 写同款· GEO 优化 ›

使用PCIE的TTE卡遇到的rcu: INFO: rcu_sched self-detected stall on CPU问题解决 RCU一个说明网页 cat或者 tail -f命令日志文件说明 /var/log/message 系统启动后的信息和错误日志，是Red Hat Linux中最常用的日志之一 /var/log/secure 与安全相关的日志信息 /var/log/maillog 与邮件相关的日志信息 /var/log/cron 与定时任务相关的日志信息 /var/log/spooler 与UUCP和news设备相关的日志信息 /var/log/boot.log 守护进程启动和停止相关的日志消息系统： # 阅读详情

在RHEL 7 和 SELS11 SP2 之后的Linux系统上，有时会看到如下信息：

INFO: rcu_sched_state detected stall on CPU 5 (t=2500 jiffies)

INFO: rcu_bh_state detected stalls on CPUs/tasks: { 3 5 } (detected by 2, 2502 jiffies)

它们来自RCU CPU Stall Detector，要了解RCU CPU Stall Detector是什么，首先要知道RCU是什么。RCU(Read-Copy Update) 是Linux 2.6 内核开始引入的一种新的锁机制，与spinlock、rwlock不同，RCU有其独到之处，它只适用于读多写少的情况。

RCU是基于其原理命名的，Read-Copy Update，[Read]指的是对于被RCU保护的共享数据，reader可以直接访问，不需要获得任何锁；[Copy Update]指的是writer修改数据前首先拷贝一个副本，然后在副本上进行修改，修改完毕后向reclaimer(垃圾回收器)注册一个回调函数(callback)，在适当的时机完成真正的修改操作–把原数据的指针重新指向新的被修改的数据，–这里所说的适当的时机就是当既有的reader全都退出临界区的时候，而等待恰当时机的过程被称为grace period 。在RCU机制中，writer不需要和reader竞争任何锁，只在有多个writer的情况下它们之间需要某种锁进行同步作，如果写操作频繁的话RCU的性能会严重下降，所以RCU只适用于读多写少的情况。

RCU API 最核心的函数是：
rcu_read_lock()
rcu_read_unlock()
synchronize_rcu()
call_rcu()

rcu_read_lock()和rcu_read_unlock()配对使用，由reader调用，用以标记reader进入/退出临界区。夹在这两个函数之间的代码区称为”读端临界区”(read-side critical section)，注：读端临界区可以嵌套。reader在临界区内是不能被阻塞的。
synchronize_rcu()由writer调用，它会阻塞writer（即writer会进入睡眠等待），直到经过grace period后，即所有的reader都退出读端临界区，writer才可以继续下一步操作。如果有多个writer调用该函数，它们将在grace period之后全部被唤醒。
call_rcu()是synchronize_rcu()的非阻塞版本，它也由 writer调用，但不会阻塞writer（即writer不会进入睡眠，而是继续运行），因而可以在中断上下文或 softirq 中使用，而 synchronize_rcu()只能在进程上下文使用。call_rcu()把参数中指定的callback函数挂接到 RCU回调函数链上，然后立即返回。一旦所有的 CPU 都已经完成端临界区操作（即grace period之后），该callback函数将被调用，用writer修改过的数据副本替换原数据并释放原数据空间。需要指出的是，函数 synchronize_rcu 的实现实际上也使用了函数call_rcu()。

RCU API 有一些特殊用途的分支，比如 RCU BH (防DDoS攻击的API)、 RCU Sched (适用于 scheduler 和 interrupt/NMI-handler 的 API)，等。参见 http://lwn.net/Articles/264090/

RCU在Linux 2.6内核中(RHEL6和SLES11 SP1)就已经存在了，那时处理 grace period 利用了软中断(softirq)，而到了新的3.x内核之后有所改变，处理grace period利用的是内核线程，因为内核线程可以被抢占，减少了实时任务的响应延迟。所以在3.x内核的系统上，会看到类似如下的内核线程：
[rcu_sched]
[rcu_bh]
[rcuob/0]
[rcuob/1]
[rcuos/0]
[rcuos/1]
还有可能会见到rcu_preempt线程。
注：其中 rcuob/N, rcuos/N 是负责处理 RCU callbacks 的内核线程，参见https://www.kernel.org/doc/Documentation/kernel-per-CPU-kthreads.txt 。

好了，现在终于可以讲 RCU CPU Stall Detector 了，它其实是RCU代码中的一个debugging feature(参见https://lwn.net/Articles/301910/ )，在2.6内核中缺省是关闭的，而到3.x内核中缺省是打开的，它有助于检测导致 grace period 过度延迟的因素，因为grace period的长短是RCU性能的重要因素。发生RCU grace period延迟会在系统日志中记录告警信息，称为 RCU CPU Stall Warnings ：

INFO: rcu_sched_state detected stalls on CPUs/tasks: { 15} (detected by 17, t=15002 jiffies)
或
INFO: rcu_bh_state detected stalls on CPUs/tasks: { 3 5 } (detected by 2, 2502 jiffies)
等等。

在上述告警信息之后通常还会看到相关CPU的stack dump，检查stack trace有助于了解当时运行的代码和可能导致延迟的原因。

如果你不想看到以上告警信息，可以通过以下参数关掉它：
/sys/module/rcupdate/parameters/rcu_cpu_stall_suppress
注：缺省值为0，表示显示延迟告警；置为1表示禁止显示延迟告警。
RCU grace period延迟多长时间会触发告警呢？这是以下参数决定的（以秒为单位）：
/sys/module/rcupdate/parameters/rcu_cpu_stall_timeout
RCU的其它内核参数，如rcupdate.rcu_task_stall_timeout等参见：
https://www.kernel.org/doc/Documentation/kernel-parameters.txt

有哪些原因会导致 RCU grace period延迟(RCU CPU Stall Warnings)呢？参见https://www.kernel.org/doc/Documentation/RCU/stallwarn.txt 这里仅列举几例：