RCU stall 根本原因是 callback 积压或 grace period 过长，需结合 rcu_nocbs、rcu_kthreads 等启动参数及 rcu_cpu_stall_timeout 等运行时参数协同调优，而非单纯调大超时。
RCU stall 检测到 CPU 卡住，本质是 RCU callback 积压或 grace period 过长，不是简单调大超时就能解决的。
rcu\_sched 和 rcu\_bh 的 stall 超时机制差异
内核通过 rcu_cpu_stall_timeout 控制 stall 检测周期（单位：秒），但 rcu_sched 和 rcu_bh 共享同一套检测逻辑，不区分独立超时值。真正影响 stall 触发时机的是：
-
rcu_cpu_stall_timeout：默认 21 秒，超过该时间未完成 grace period 就报rcu detected stall on CPU -
rcu_cpu_stall_info：设为 1 可在 stall 发生时打印更多上下文（如最近的rcu_pending、rcu_qs状态） -
rcu_nocbs：若启用（如rcu_nocbs=1），会把 callback 移出 softirq，在 kthread 中执行，可能缓解 softirq 堵塞导致的rcu_bhstall
常见触发场景与对应参数调整建议
不能只改超时值，得先定位卡点类型：
- 高负载下 softirq 处理不过来（尤其
rcu_bh）→ 启用rcu_nocbs并绑定到隔离 CPU：rcu_nocbs=1 isolcpus=noirq,managed_irq,1-3 - 长时间关中断（
local_irq_disable）或禁抢占（preempt_disable）→ 检查驱动或模块，rcu_cpu_stall_timeout调小（如 5）反而更容易暴露问题 - 大量 callback 积压（如频繁
call_rcu+ 长耗时 callback）→ 改用call_rcu_tasks或拆分 callback 工作，避免阻塞 RCU softirq -
虚拟化环境（KVM）中 vCPU 被调度器长期挂起 → 调大
rcu_cpu_stall_timeout是合理妥协，但需配合rcu_kthreads=1启用专用 kthread 加速 grace period
/proc/sys/kernel/ 下可运行时修改的关键参数
这些参数支持 sysctl 或 echo 写入，适合调试阶段快速验证：
-
/proc/sys/kernel/rcu_cpu_stall_timeout：例如echo 60 > /proc/sys/kernel/rcu_cpu_stall_timeout -
/proc/sys/kernel/rcu_cpu_stall_info：设为1获取更详细 stall trace -
/proc/sys/kernel/rcu_normal：仅在启用CONFIG_RCU_NOCB_CPU=y时存在，控制 nocb CPU 列表（如0,2）
注意：rcu_nocbs 必须在 boot 参数中指定，运行时无法开启；而 rcu_kthreads 也必须启动时设置（rcu_kthreads=1）才能启用 RCU kthread。
容易被忽略的硬性限制
RCU stall 检测本身依赖定时器和 softirq 投递，如果系统已严重失调度（如所有 CPU 长期处于 idle 或被独占），rcu_cpu_stall_timeout 可能根本不会触发——它不是 watchdog，而是基于 RCU 自身状态轮询。真正要抓这类问题，得结合 ftrace 跟踪 rcu_utilization 和 rcu_grace_period 事件，而不是只盯着超时参数调大。
