rcu_sched stall超时由RCU_STALL_DELAY_DELTA和rcu_cpu_stall_timeout控制，后者默认21秒且可通过sysctl动态调整；rcu_bh stall共享该参数但实际判定窗口更短，无独立调控接口。
rcu_sched stall 超时时间由哪些参数控制
内核中 rcu_sched stall 检测的超时阈值不是固定值，而是基于 CPU tick 频率和预设的“stall timeout 倍数”动态计算。核心控制参数是 RCU_STALL_DELAY_DELTA（编译期常量）和运行时可调的 rcu_cpu_stall_timeout，后者默认为 21 秒（即 21 * HZ / 1000 毫秒级 tick 对齐）。该值可通过 sysctl 修改：
-
echo 30 > /proc/sys/kernel/rcu_cpu_stall_timeout—— 将 stall 报告阈值设为 30 秒 - 该修改仅影响新触发的 stall 检测，已发生的 stall 不会重置计时器
- 需确保内核配置了
CONFIG_RCU_CPU_STALL_INFO=y，否则该 sysctl 不存在
rcu_bh stall 和 rcu_sched 的 timeout 是否共用参数
不共用。rcu_bh stall 的检测逻辑与 rcu_sched 独立，但共享同一套超时机制：它也读取 rcu_cpu_stall_timeout，但实际生效的 stall 判定窗口更短——因为 rcu_bh 的 grace period 通常极短（微秒级），其 stall 检测在内部会按比例压缩等待时间。关键点：
-
rcu_bhstall 不受独立 sysctl 控制；没有类似rcu_bh_stall_timeout的接口 - 若看到
rcu_bhstall 日志，往往意味着 softirq 处理被长时间阻塞（如驱动在 softirq 中死循环、关中断过久） - 不能靠调大
rcu_cpu_stall_timeout来掩盖rcu_bhstall，这只会延迟报警，不解决根本问题
调大 rcu_cpu_stall_timeout 能解决假阳性吗
能缓解部分场景，但有明确边界。常见适用情况包括：
- 系统启用了
nohz_full（无滴答模式）且某个 CPU 长时间运行独占线程，导致 RCU callback 积压 - 内核调试配置（如
CONFIG_PROVE_RCU或锁依赖检查）显著拖慢 grace period 完成 - 极端负载下（如大量进程 fork/exit + RCU callback 爆发），callback 处理队列延迟超过默认 21 秒
但以下情况调大参数无效甚至有害：
- 真实 lockup（如自旋锁死锁、中断被禁用超 1s）—— stall 是症状，不是原因
- RCU callback 中执行耗时操作（如 kmalloc + disk I/O）——应改用 workqueue 异步处理
- 误将
call_rcu()用于短生命周期对象，导致 callback 队列膨胀
真正需要检查的底层线索
stall 日志末尾的 backtrace 和 CPU state 才是关键。重点关注：
- 报 stall 的 CPU 当前是否在
__do_softirq、rcu_core或某驱动函数中停滞？—— 指向 softirq 或 callback 实现问题 - 是否显示
rcu_preempt同时 stall？—— 可能是 PREEMPT_RT 补丁行为异常或抢占被意外关闭 -
rcu_schedstall 时，对应 CPU 的jiffies是否几乎不动？—— 暗示该 CPU 已完全 hang 住，而非 RCU 本身慢 -
/proc/sys/kernel/rcu_expedited若为 1，可能因频繁强制 expedited GP 导致 overload
RCU stall 不是性能调优项，而是系统健康探针。参数调整只是临时掩耳盗铃，真正要盯的是 stall 发生时那个 CPU 正在干什么。
