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_bh stall 不受独立 sysctl 控制；没有类似 rcu_bh_stall_timeout 的接口
• 若看到 rcu_bh stall 日志，往往意味着 softirq 处理被长时间阻塞（如驱动在 softirq 中死循环、关中断过久）
• 不能靠调大 rcu_cpu_stall_timeout 来掩盖 rcu_bh stall，这只会延迟报警，不解决根本问题

调大 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_sched stall 时，对应 CPU 的 jiffies 是否几乎不动？—— 暗示该 CPU 已完全 hang 住，而非 RCU 本身慢
• /proc/sys/kernel/rcu_expedited 若为 1，可能因频繁强制 expedited GP 导致 overload

RCU stall 不是性能调优项，而是系统健康探针。参数调整只是临时掩耳盗铃，真正要盯的是 stall 发生时那个 CPU 正在干什么。