CPU隔离 – HDUO Lab

滥用 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 即可达到最佳实践。

某次线上核心交易集群出现诡异的 Node 批量假死现象。故障发生时，API 响应瞬间超时（p99 从 2ms 飙升至 10s 以上），K8S 节点状态接连翻转为 NotReady，SSH 彻底失去响应。监控面板在断点前最后上报的数据显示：系统 Load Average 飙升至 800+，某几个单核 CPU 突然被打至 100%。

最终结论：研发为了追求极致的低延迟，在业务代码中强行将关键线程的调度策略修改为 SCHED_FIFO（实时调度，优先级 99），并且在这个线程里写了一个没有退让机制的死循环 Spinlock。这导致对应的 CPU 核被完全霸占，内核态的 RCU (Read-Copy Update) 宽限期线程、ksoftirqd 等关键内核线程被彻底饿死，最终触发 rcu_sched stall，引发系统 Soft Lockup 进而 Panic。

现场还原与死亡日志

排查这种彻底死机的节点，常规的 top 或 strace 根本来不及敲，只能依赖保留的 kdump 或者重启后的 dmesg 遗言。在 messages 日志中，我提取到了最核心的崩溃栈：

[ 1345.678901] watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [bidding_worker:45092]
[ 1345.678915] INFO: rcu_sched self-detected stall on CPU
[ 1345.678920]  4-....: (59999 ticks this GP) idle=001/1/0x4000000000000000 softirq=45123/45123 fqs=14998
[ 1345.678925]  (t=60000 jiffies g=123456 q=8901)
[ 1345.678931] NMI backtrace for cpu 4
[ 1345.678950] RIP: 0033:0x00007f8a9b2c3d4e (用户态死循环地址)

日志非常清晰：CPU 4 卡死了 22 秒，RCU 机制检测到宽限期（Grace Period）已经 60000 个 jiffies 没有推进了。卡死 CPU 的进程是 bidding_worker，且 RIP 寄存器停留在用户态 (0033)。

这意味着，不是内核出了 Bug，而是用户态进程死死咬住 CPU 不放，连内核的中断下半部和调度器都抢不回控制权。

为什么用户态能干掉内核态？

我拉取了该进程的调度配置，破案了：

$ chrt -p 45092
pid 45092's current scheduling policy: SCHED_FIFO
pid 45092's current scheduling priority: 99

这正是让人血压升高的操作。在 Linux 调度器（CFS，Completely Fair Scheduler）面前，所有普通进程（SCHED_OTHER）都要乖乖按时间片和 vruntime 来排队。但 SCHED_FIFO 和 SCHED_RR 属于 Real-Time（实时）调度类，它的权限是凌驾于 CFS 之上的。

SCHED_FIFO 的语义是：只要该线程不主动睡眠（sleep/wait）、不主动让出 CPU（sched_yield），或者不被更高优先级的 RT 线程抢占，它就会永远霸占当前的 CPU 核。

业务代码里是怎么写的？

// 致命的自旋锁逻辑
while (!atomic_load(&task_ready)) {
    // 没有任何 sleep，没有 cpu_relax()，没有 sched_yield()
    // 纯纯的死循环烧 CPU
}

当优先级设定为 99 的 SCHED_FIFO 线程进入上述死循环时，灾难开始了：

抢占屏蔽：内核的普通调度器完全无法剥夺它的执行权。
RCU 饿死：Linux 内核广泛使用 RCU 机制来管理无锁数据结构。RCU 需要等待所有 CPU 经过一次上下文切换（Quiescent State）来清理旧数据。CPU 4 被死循环霸占，永远不发生上下文切换，RCU 宽限期无限延长，内存无法释放，最终触发 RCU Stall Panic。
软中断阻塞：网卡收发包依赖的 ksoftirqd 默认也是普通优先级。CPU 4 上的网络包无法被处理，导致网络层面的“假死”。

消失的最后一道防线

按理说，Linux 内核对这种 RT 调度器的滥用是有防御机制的。kernel.sched_rt_runtime_us 和 kernel.sched_rt_period_us 这两个 sysctl 参数，默认配置为每 1000000 微秒（1秒）内，RT 进程最多只能运行 950000 微秒（0.95秒）。剩下的 0.05 秒会强制留给普通进程（比如内核线程）续命。

为什么没生效？排查发现，某位前任 SRE 为了追求极限的内核调优，在初始化的 Ansible 剧本里加了一行： sysctl -w kernel.sched_rt_runtime_us=-1

将该值设为 -1，意味着彻底关闭了 RT 进程的运行时间限制，扒光了内核的最后底裤。两者结合，精准击穿了系统的可用性防线。

极低延迟的正确实现姿势

如果业务真的需要旁路内核、避免调度开销来实现极低延迟（如 DPDK/SPDK 架构），绝不是简单粗暴地改个 SCHED_FIFO 就能搞定的。正确的系统级架构应该走CPU 隔离与绑核的路线：

内核启动参数隔离：通过 Grub 传入 isolcpus=4-7 nohz_full=4-7 rcu_nocbs=4-7。这会让操作系统把 CPU 4 到 7 隔离开，不往上面扔普通的定时器中断，不调度普通进程，并将 RCU 回调转移到其他核。
中断亲和性调整：配置 irqbalance 或手动修改 /proc/irq/xxx/smp_affinity，确保网卡和磁盘的硬件中断不要打到被隔离的核上。
应用侧精准绑核：业务进程启动后，使用 taskset 或 pthread_setaffinity_np，将死循环 Polling 的线程严格绑定在上述隔离核上。

这时候，你用死循环轮询没有任何问题，因为这几个核本来就是买来专门给你“烧”的，不会影响系统大盘。

排查清单与同类问题速查

RCU Stall 定位确认 通过 dmesg -T | grep -i rcu_sched 查看是否有 self-detected stall。如果有，必须顺着堆栈找到是哪个 PID 卡死了特定的 CPU，并且留意 ticks this GP 是否异常庞大。
全网进程调度策略巡检 排查系统中是否有越权的调度策略：ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,comm | awk '$3 != "TS" && $3 != "-" {print $0}' （TS 代表 SCHED_OTHER，重点关注 FF/RR 类型的进程）。
内核防御机制校验 检查 /proc/sys/kernel/sched_rt_runtime_us 是否被手贱修改为 -1。在非专用的隔离物理机上，强烈建议保持默认值 950000。
自旋锁的防御性编程 在任何 C/C++/Rust 的用户态 Spinlock 实现中，循环体内必须加入 cpu_relax()（在 x86 下编译为 PAUSE 指令），这不仅能降低 CPU 流水线功耗，也能缓解总线争用。

标签： CPU隔离

深入 Linux 内核调度陷阱排查：滥用 SCHED_FIFO 实时调度引发的 RCU 饥饿与 Watchdog Soft Lockup 实战