滥用 SCHED_FIFO 实时调度策略会导致 CPU 核心被 100% 霸占，进而饿死内核 RCU 线程，触发 rcu_sched stall 和 Watchdog 软死锁。本文还原一次宿主机内核 Panic 现场，深度解析 RT 调度器与 CFS 抢占机制，并给出通过 isolcpus 与 RT 节流阀实现安全绑核的终极方案。
故障现场：K8s 节点神秘失联与内核崩溃
近期在处理某低延迟网关集群的稳定性问题时，发现部分宿主机（OS: CentOS 8, Kernel 4.18.0-305.el8.x86_64）频繁触发 NotReady，随后整机无响应，只能通过 IPMI 硬重启。
遇到物理节点无响应，第一反应是接上串口控制台看系统底层的最后遗言。提取 vmcore 并在控制台日志中发现海量如下报错：
[ 3105.123456] NMI watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [gw_worker:14032]
[ 3105.123488] Modules linked in: veth ipt_MASQUERADE ...
[ 3105.123501] CPU: 4 PID: 14032 Comm: gw_worker Kdump: loaded Tainted: G W 4.18.0-305.el8.x86_64 #1
[ 3105.123512] RIP: 0033:0x00007f8a9b1c2d40
[ 3105.123520] Code: 89 d0 f3 90 48 8b 02 48 39 c0 75 f6 ... (用户态自旋指令)
...
[ 3110.134567] INFO: rcu_sched self-detected stall on CPU
[ 3110.134575] 4-....: (21000 ticks this jiffies) idle=002/1/0x4000000000000002 softirq=12345/12345 fqs=5250
日志暴露出两个致命特征：
-
Soft Lockup (软死锁)：CPU 4 被进程
gw_worker(PID 14032) 连续霸占超过 22 秒，期间没有任何调度切换。 -
RCU Stall (RCU 停滞)：内核的 RCU (Read-Copy Update) 机制检测到 CPU 4 迟迟没有经过宽限期（Quiescent State），导致全系统 RCU 回收阻塞。
查看发生 Lockup 的指令流（RIP），确认其卡在用户态地址 0x0033:...，而非陷入内核死锁。一个用户态进程，凭什么能让内核级 Watchdog 报警甚至宕机？
为什么用户态的 SCHED_FIFO 会引发内核级瘫痪？
排查过程中，直接抓取了该业务容器的启动脚本，发现开发团队为了压榨延迟，执行了以下操作：
# 业务启动脚本片段
taskset -c 4 chrt -f 99 ./gw_worker
不仅用 taskset 绑定了 CPU 4，还用 chrt -f 99 将调度策略设置为了最高优先级的实时调度 SCHED_FIFO。配合代码中无休止的 while(true) { poll_nic(); }（完全没有 sleep 或系统调用），直接引爆了调度器。
在 Linux 调度子系统中，调度类优先级严格遵循：
StopTask > Deadline (SCHED_DEADLINE) > RealTime (SCHED_FIFO/SCHED_RR) > Fair (SCHED_NORMAL/CFS) > Idle
底层机制解析：
-
抢占机制失效：
SCHED_FIFO属于实时调度类。对于 FIFO 策略，除非它主动yield()，或者被更高优先级的实时任务抢占，否则它将永远独占所在的 CPU 的 Runqueue。 -
内核线程饿死：内核中有许多关键的后台线程（如
ksoftirqd、RCU 宽限期处理线程等），它们的默认调度策略是 CFS (SCHED_NORMAL)。当 CPU 4 上跑满了一个死循环的SCHED_FIFO任务时，CFS 队列中的任务连 1 纳秒的时间片都分不到。 -
软死锁触发：NMI Watchdog 是一个基于高精度定时器（hrtimer）的机制，它依赖内核能够定期响应中断并更新时间戳。当 CPU 完全被用户态 Spin-loop 锁死，且内核软中断（Softirq）被饿死时，Watchdog 计时器超时，判定 CPU 陷入软死锁，触发 Panic（若配置了
kernel.softlockup_panic = 1）。
致命的配置漂移：RT 节流阀被关
有经验的内核玩家会问：Linux 默认启用了 RT Throttling（实时任务节流机制），允许 RT 任务最多运行 95% 的时间，剩下 5% 强制留给 CFS，为什么没起作用？
检查宿主机内核参数：
$ sysctl kernel.sched_rt_runtime_us
kernel.sched_rt_runtime_us = -1
真相大白。某次系统级优化中，运维人员为了消除所谓的“调度抖动”，将 kernel.sched_rt_runtime_us 设为了 -1（彻底禁用 RT 限制）。这把最后一道安全阀拔掉了，导致 gw_worker 实现了一刀切的完全独占。
终极解决方案：防御性配置与规范化绑核
在生产环境中，要既满足低延迟诉求，又保证系统不发生雪崩，必须实施防御性隔离。
方案一：恢复并优化 RT 节流机制 (快速止血)
绝对禁止全局禁用 RT Throttling。将其恢复为默认值，或者适当放宽但不允许等于 -1：
# 默认总周期 1000000 us (1s)
sysctl -w kernel.sched_rt_period_us=1000000
# 允许 RT 任务最多运行 980000 us (98%)，留 20ms 给内核及 CFS 兜底
sysctl -w kernel.sched_rt_runtime_us=980000
这 2% 的时间足以让 RCU 完成宽限期推进，彻底消除 rcu_sched stall 和 Soft Lockup。
方案二：内核级极致隔离 (isolcpus + nohz_full)
如果业务（如高频交易 DPDK 场景）确实连 2% 的调度抖动都无法忍受，必须进行系统级的彻底隔离。通过内核启动参数，将特定 CPU 从内核的常规调度器中剥离。
修改 /etc/default/grub 中的 GRUB_CMDLINE_LINUX：
# 假设隔离 CPU 4,5
isolcpus=4,5 nohz_full=4,5 rcu_nocbs=4,5 irqaffinity=0-3
原理解析：
-
isolcpus=4,5：将 CPU 4 和 5 从 CFS 负载均衡域中剔除，常规进程绝不会被调度过去。 -
nohz_full=4,5：禁用该 CPU 上的时钟 Tick 中断（Adaptive-Ticks），避免每秒 1000 次（HZ=1000）的定时器中断打断用户态 Spin-loop。 -
rcu_nocbs=4,5：将 RCU 的回调（Callbacks）转移到其他 CPU 上执行，防止该 CPU 不响应调度引发 RCU Stall。 -
irqaffinity=0-3：将所有外部硬件中断限制在非隔离的 CPU 上。
应用后重启：
grub2-mkconfig -o /boot/grub2/grub.cfg
reboot
之后业务再通过 taskset -c 4 运行。由于该 CPU 上没有任何其他竞争者（内核中断也被驱逐），业务甚至不需要使用危险的 SCHED_FIFO，直接用普通 SCHED_NORMAL 跑满即可实现 0 调度上下文切换。
常见问题 (Q&A)
Q1：如果是普通的 CFS 调度任务死循环导致 CPU 100%，会触发 Soft Lockup 吗？
不会。CFS（完全公平调度器）保证了时间片的相对公平。即使进程写了死循环跑满 100%，当时钟中断（Tick）到来或时间片耗尽时，内核仍能强制剥夺其执行权，调度 ksoftirqd 和 Watchdog 线程，不会引发内核饿死。
Q2：如何快速监控系统中是否存在滥用实时调度策略的危险进程？
可以通过 ps 命令直接排查，提取调度策略 (policy) 为 FF (FIFO) 或 RR (Round Robin) 的进程：
# rtprio 为实时优先级, psr 为当前运行的 CPU
ps -eo pid,ni,pri,rtprio,psr,comm,policy | grep -E 'FF|RR'
Q3：在 Kubernetes 中，应该如何规范地分配独立 CPU 给低延迟业务？
不要在容器内使用 taskset 乱绑。应启用 Kubelet 的 CPU Manager（设置 --cpu-manager-policy=static），并将 Pod 的资源请求配置为 Guaranteed QoS（requests.cpu 等于 limits.cpu，且为整数）。Kubelet 底层会通过 cgroup cpuset 子系统将独占 CPU 分配给容器，避免与其他 Pod 产生资源争抢，此时配合宿主机的 isolcpus 即可达到最佳实践。