标签： SCHED_FIFO

深入 Linux 内核调度陷阱排查：滥用 SCHED_FIFO 引发的 RCU 饥饿与节点 Hard Lockup 实战
某次接手排查一个核心低延迟网关的间歇性“假死”问题。现象极为惨烈：物理节点突然与控制面失联，监控指标白屏，SSH 无法建立连接（TCP 握手超时），但基础的 ICMP Ping 依然能通。最终强制重启并在终端外接主板收集到了崩溃现场。

结论先行：业务开发为了追求所谓的“极致低延迟”，绕过 SRE 压测体系，在 systemd service 中私自将网关进程的 CPU 调度策略设置为 SCHED_FIFO（实时调度）且优先级拉满到 99，甚至顺手把内核保护机制 kernel.sched_rt_runtime_us 改成了 -1。这种鲁莽的操作导致用户态死循环轮询（Busy-Polling）线程霸占了 CPU，直接饿死内核 RCU (Read-Copy Update) 宽限期线程和其他系统守护进程，最终触发内核 Watchdog 机制，导致节点引发 Hard Lockup 彻底瘫痪。

正确的低延迟调优绝不是靠暴力抢占调度权，而是通过 isolcpus、NO_HZ_FULL 以及网卡中断亲和性绑定来实现 CPU 的“纯净隔离”。

事故现场：SSH 进不去的诡异假死

排查过程中，通过带外管理（IPMI）查看崩溃前的系统终端，满屏飘着内核报错日志。提取出的核心堆栈如下：
```
watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [gateway-worker:14322]
...
rcu: INFO: rcu_sched self-detected stall on CPU
rcu:     4-....c1e.. dps: 125199 GPs: 43232121
rcu:     (t=60000 jiffies g=123321 q=123)
Task dump for CPU 4:
task:gateway-worker  state:R  running task    stack:0     pid:14322 ppid:1
Call Trace:
 <IRQ>
 rcu_dump_cpu_stacks+0xdf/0x110
 rcu_check_callbacks+0x7b5/0x8e0
 update_process_times+0x2c/0x50
 tick_sched_timer+0x4d/0x90
 __hrtimer_run_queues+0x10b/0x290
 hrtimer_interrupt+0xf4/0x210
 smp_apic_timer_interrupt+0x5e/0x120
 ...
```
从日志看，CPU 4 陷入了长达 22 秒的 Soft Lockup，随后 RCU 机制检测到了 CPU 停滞（Stall）。当前在这个 CPU 上运行的进程正是业务的核心网关程序 gateway-worker。

为什么 SSH 连不上但 Ping 能通？因为 ICMP 包的响应通常在网卡软中断（SoftIRQ）上下文中处理，而 SSHD 是运行在完全公平调度器（CFS）下的普通用户态进程。如果 CPU 被比 CFS 优先级更高的任务死死咬住，普通进程根本分不到时间片，连 shell 提示符都弹不出来。

扒开配置的底裤：夺命的优先级

挂载崩溃节点的系统盘后，我直接翻看了业务侧提交的 systemd 配置文件，发现了令人窒息的代码片段：
```
[Service]
ExecStart=/opt/gateway/bin/gateway-worker
# 业务开发自行添加的“性能优化”配置
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=99
```
不仅如此，他们在服务的 pre-start 脚本中，还加入了这样一行 sysctl 注入：
```
sysctl -w kernel.sched_rt_runtime_us=-1
```
这套组合拳的逻辑漏洞在于，他们完全没有理解 Linux 内核调度类的层次结构。

Linux 调度器分为不同的调度类，优先级从高到低依次为： Stop > Deadline > Real-Time (RT) > Completely Fair Scheduler (CFS) > Idle。

业务代码使用的 SCHED_FIFO 属于 RT 调度类。在 SCHED_FIFO 策略下，一旦线程拿到 CPU，除非它主动让出（阻塞于 I/O、调用 sched_yield），或者被更高优先级的 RT 线程抢占，否则它将永远运行下去。而该网关程序为了降低网络处理延迟，采用了类似于 DPDK 的 Busy-Polling 模式（死循环空跑轮询队列）。

正常情况下，Linux 为了防止这种流氓进程锁死系统，内核有一个保护参数 /proc/sys/kernel/sched_rt_runtime_us，默认值为 950000（即每秒钟最多允许 RT 进程运行 950ms，必须留 50ms 给非 RT 进程如 CFS 调度类）。但这位开发者不知从哪搜来的“黑魔法”，把这个值改成了 -1（完全关闭限制）。

结果是灾难性的：优先级 99 的死循环线程独占了 CPU。内核的 RCU 宽限期线程（rcu_sched）、迁移线程（migration）、甚至是负责清理内存的内核工作队列，全部被饿死。RCU 无法推进，系统内部锁积压，最终 Watchdog 狗咬死，节点硬重启。

真正的防御性调优：如何正确榨干 CPU 性能？

追求低延迟，不应该在调度器上玩火，而是要通过CPU 隔离与亲和性绑定，把 CFS 的干扰降到最低。

正确的改造方案如下：

1. 隔离 CPU，避免系统进程干扰 在 Grub 内核启动参数中，将部分核心（如物理核 4-15）完全隔离开来，不参与普通进程的 CFS 调度，并开启无滴答模式（减少时钟中断）：
```
GRUB_CMDLINE_LINUX="... isolcpus=4-15 nohz_full=4-15 rcu_nocbs=4-15"
```
这样，这几个核心将被彻底“净化”，系统默认进程不会跑在上面。

2. 使用 cset 或 taskset 绑定业务进程 将业务进程锁定在这些被隔离的核心上。在 systemd 中，使用 CPUAffinity 替代愚蠢的 CPUSchedulingPolicy：
```
[Service]
ExecStart=/opt/gateway/bin/gateway-worker
CPUAffinity=4-15
# 确保不要使用 fifo 策略，保持默认的 other (CFS) 即可
```
3. 剥离网卡中断 默认情况下，irqbalance 服务会在所有 CPU 上随机分配网卡硬中断。为了防止网卡中断打断我们的轮询线程，需要修改 irqbalance 配置，或者手动设置网卡的 SMP affinity，将中断绑定到非隔离的 CPU（如 0-3）上。

通过这套“隔离+绑定”的方案，业务进程在独占的 CPU 核心上运行，既能享受近似 100% 的时间片（无上下文切换抖动），又不会影响内核在其他核心上处理基础系统任务，这才是真正企业级高可用的落地做法。

排查清单与同类问题速查
1. RCU Stall / Soft Lockup 初判：dmesg 如果频繁出现 rcu_sched self-detected stall 或 BUG: soft lockup，首查占用该 CPU 的进程是否进入了死循环，其次查是否滥用了实时调度优先级。
2. 实时调度策略审查：使用 chrt -m 查看系统支持的优先级范围，使用 ps -eo pid,ni,rtprio,psr,comm,policy | grep FIFO 审查生产环境是否存在未经审批的 SCHED_FIFO 或 SCHED_RR 进程。
3. RT 防御机制检查：绝不要在生产环境将 kernel.sched_rt_runtime_us 设为 -1。如果确需微调，请保留至少 50000（50ms）的余量给系统进程。
4. 低延迟优化正规军：对 CPU 密集型或轮询型低延迟业务，标准答案是 isolcpus 隔离 + taskset 亲和性绑定 + nohz_full 关闭时钟滴答，切勿试图通过篡改全局调度策略来插队。
5. 假死现象倒推：如果 SSH 无法登录但 Ping 延迟极低且稳定，说明网络中断层正常但用户态调度已瘫痪，重点排查 CPU 抢占和 OOM 导致的 fork 拒绝。
2026年8月25日
深入 RT 调度陷阱排查：SCHED_FIFO 引发的 RCU Stall 与 CPU 亲和性假死实战
盲目将业务进程设置为 SCHED_FIFO（实时调度）并绑核，若未保留内核线程调度余量，会直接饿死同核的 RCU 回调与 kworker，触发 rcu_sched stall 导致节点假死。解法：恢复 sched_rt_runtime_us 节流，高并发组件应优先使用 CFS 结合 cpuset 绑核，严禁滥用 RT 调度。

故障现场：P99 飙升与节点失联

某次排查高频交易网关的性能问题时，业务侧反馈部分节点的 P99 延迟会突然从 2ms 飙升至 3000ms 以上，甚至出现短暂的连接超时。登录问题节点（Kernel 5.10.112-11）发现，Load Average 异常飙升至所在 CPU 核数以上，SSH 交互出现明显卡顿，但整体内存和磁盘 IO 并无压力。

查看系统内核日志，直接抓到核心报错：
```
$ dmesg -T | tail -n 20
[Tue Oct 24 14:12:33] INFO: rcu_sched self-detected stall on CPU
[Tue Oct 24 14:12:33]   12-....c.: (59999 ticks this GP) idle=31a/1/4611686018427387906 softirq=1028321/1028321 fqs=14995
[Tue Oct 24 14:12:33]    (t=60000 jiffies g=2431213 q=101345)
[Tue Oct 24 14:12:33] NMI backtrace for cpu 12
...
[Tue Oct 24 14:12:33] RIP: 0010:gateway_poll_loop+0x45/0x120 [gateway_bin]
...
```
日志非常明确：CPU 12 上发生了 rcu_sched stall（RCU 宽限期超时）。内核检测到 CPU 12 上的 RCU grace period 已经停滞了 60000 个 jiffies（通常是 60 秒），并且抓到的现场 RIP 寄存器停留在业务进程 gateway_bin 的轮询函数 gateway_poll_loop 中。

剥丝抽茧：谁霸占了 CPU？

既然业务进程在 CPU 12 上死循环或高负载，第一步是检查该进程的调度策略和 CPU 亲和性。

抓取目标进程的 PID，查看其调度属性：
```
$ chrt -p 48291
pid 48291's current scheduling policy: SCHED_FIFO
pid 48291's current scheduling priority: 99

$ taskset -cp 48291
pid 48291's current affinity list: 12
```
结果一目了然：开发为了追求极致延迟，通过 sched_setscheduler 将该网关的轮询线程设置成了 SCHED_FIFO（实时调度），优先级拉到了最高的 99，并且通过 sched_setaffinity 强行绑定在了 CPU 12 上。

顺手检查一下系统的 RT 调度全局限制：
```
$ sysctl kernel.sched_rt_runtime_us
kernel.sched_rt_runtime_us = -1
```
发现 kernel.sched_rt_runtime_us 被改为了 -1（无限制）。这就是彻头彻尾的“自杀式”调优。

为什么 SCHED_FIFO 结合绑核会引发系统假死？

在 Linux 内核的调度子系统中，调度类（Scheduling Class）是有严格层级关系的：Stop > Deadline > Real-Time (RT) > Fair (CFS) > Idle。

SCHED_FIFO 属于 RT 调度类，其优先级碾压普通的 CFS 调度任务。当一个 SCHED_FIFO 线程进入 Runnable 状态时，它会无条件抢占当前 CPU 上的 CFS 线程，并且只有在它主动让出 CPU（如 sleep、IO 阻塞）或被更高优先级的 RT 任务抢占时，才会交出执行权。

在本案中，网关线程是一个 while(1) 的密集轮询（Poll）循环，不包含任何阻塞系统调用。这就导致了以下连锁反应：
1. 绝对霸占：该线程在 CPU 12 上以 SCHED_FIFO 优先级 99 运行，永远不会主动 yield。
2. 内核线程饿死：Linux 内核依赖每 CPU 的 ksoftirqd（处理软中断，如网络包处理）、rcuc（RCU 回调处理）等内核线程来维持系统运转。这些内核线程大部分默认是 CFS 调度。
3. RCU 宽限期停滞：RCU（Read-Copy-Update）机制依赖各 CPU 周期性地报告 quiescent state（静止状态）来结束 Grace Period，进而回收内存。CPU 12 上的 rcuc 线程被彻底饿死，无法上报静止状态。
4. 全局雪崩：其他 CPU 上的写操作在等待 RCU Grace Period 结束，由于 CPU 12 一直不上报，整个系统的 RCU 回收被阻塞。随着时间推移，系统内存无法回收，其他依赖 RCU 同步的内核路径全部卡死，最终触发 rcu_sched stall，甚至引发 Watchdog 触发 NMI 宕机（如果开启了 kernel.unknown_nmi_panic）。
内核原本有一个保护机制：kernel.sched_rt_period_us（默认 1000000，即 1s）和 kernel.sched_rt_runtime_us（默认 950000，即 0.95s）。这意味着在每 1 秒内，RT 任务最多只能运行 0.95 秒，强制留出 50ms 给普通的 CFS 任务和内核线程运行。但排查过程中发现，有人为了“避免这 50ms 的毛刺”，将 sched_rt_runtime_us 设置成了 -1，彻底关闭了 RT 节流保护，直接把系统推向了深渊。

破局与架构优化：防御性调度

针对高频网关/DPDK/Redis等对延迟极度敏感的场景，正确的调优姿势绝不是盲目开 SCHED_FIFO，而是通过“隔离与独占”在 CFS 下实现类似 RT 的效果。

1. 紧急止血：恢复 RT 节流

立即将 sched_rt_runtime_us 恢复为默认值，给内核线程留出活路。
```
sysctl -w kernel.sched_rt_runtime_us=950000
```
注：即使业务出现少量 P99 毛刺，也比整个 Node 假死要好。

2. 长期重构：isolcpus + NOHZ_FULL + CFS

废弃代码中的 SCHED_FIFO 设置，改回默认的 SCHED_OTHER (CFS)。利用内核参数将特定 CPU 从调度器和中断中隔离出来，让业务线程在干净的 CPU 上运行。

在 Grub 内核启动参数中添加：
```
isolcpus=12 nohz_full=12 rcu_nocbs=12
```
- isolcpus=12：将 CPU 12 从内核调度器的普通负载均衡域中剥离，CFS 不会主动将其他进程调度到该核。
- nohz_full=12：当 CPU 12 上只有一个 Runnable 进程时，关闭 Tick 时钟中断，消除 1000Hz/250Hz 的调度时钟抖动。
- rcu_nocbs=12：将 CPU 12 的 RCU 回调处理卸载到其他 CPU（如 CPU 0）上执行，防止 RCU 干扰业务线程。
随后，通过 taskset 或 cgroup cpuset 将业务进程绑定到 CPU 12。此时，业务进程虽然是 CFS 调度，但在 CPU 12 上没有竞争者，既能实现接近 100% 的独占运行，又不会引发 RCU Stall。

常见问题

Q: 如何快速排查系统中是否存在滥用 SCHED_FIFO 的进程？ 使用 ps 命令可以快速拉取调度策略和优先级。FF 代表 FIFO，RR 代表 Round Robin。
```
ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,comm --sort=-rtprio | grep -v TS
```
Q: SCHED_RR (Round Robin) 能否解决这个饿死问题？ 不能。SCHED_RR 同样属于 RT 调度类，优先级依然高于 CFS。它只是在同等优先级的多个 RT 任务之间采用时间片轮转。如果同核上只有一个跑满 CPU 的 SCHED_RR 任务，它依然会饿死普通的 CFS 内核线程。

Q: 容器环境 (K8s) 中如何实现类似的安全绑核？ 在 K8s 中，通过配置 kubelet 的 --cpu-manager-policy=static，并为 Pod 申请整数型的 CPU 资源（如 requests.cpu: 2, limits.cpu: 2），K8s 会自动为其分配独占的物理 CPU（借助 cpuset cgroup）。不要在容器内自行调用 sched_setscheduler 修改为 RT 调度，容易被 cgroup 限制策略拦截或引发宿主机雪崩。

Q: 为什么有时候设置了 SCHED_FIFO 并没有引发机器死机？ 因为业务逻辑中存在 epoll_wait、sleep、网络 IO 等阻塞调用。当 RT 进程阻塞等待时，它会主动让出 CPU，此时 ksoftirqd 等内核线程就能趁机运行。只有在纯 CPU 密集型的 while(1) 死循环或高频极密轮询下，RT 任务才会真正引发系统级灾难。
2026年7月31日
深入 SCHED_FIFO 调度死锁排查：RT 优先级滥用引发的 RCU Stall 与 Node 假死实战
某次线上核心交易集群出现诡异的 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 线程进入上述死循环时，灾难开始了：
1. 抢占屏蔽：内核的普通调度器完全无法剥夺它的执行权。
2. RCU 饿死：Linux 内核广泛使用 RCU 机制来管理无锁数据结构。RCU 需要等待所有 CPU 经过一次上下文切换（Quiescent State）来清理旧数据。CPU 4 被死循环霸占，永远不发生上下文切换，RCU 宽限期无限延长，内存无法释放，最终触发 RCU Stall Panic。
3. 软中断阻塞：网卡收发包依赖的 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 隔离与绑核的路线：
1. 内核启动参数隔离：通过 Grub 传入 isolcpus=4-7 nohz_full=4-7 rcu_nocbs=4-7。这会让操作系统把 CPU 4 到 7 隔离开，不往上面扔普通的定时器中断，不调度普通进程，并将 RCU 回调转移到其他核。
2. 中断亲和性调整：配置 irqbalance 或手动修改 /proc/irq/xxx/smp_affinity，确保网卡和磁盘的硬件中断不要打到被隔离的核上。
3. 应用侧精准绑核：业务进程启动后，使用 taskset 或 pthread_setaffinity_np，将死循环 Polling 的线程严格绑定在上述隔离核上。
这时候，你用死循环轮询没有任何问题，因为这几个核本来就是买来专门给你“烧”的，不会影响系统大盘。

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

标签： SCHED_FIFO

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

事故现场：SSH 进不去的诡异假死

扒开配置的底裤：夺命的优先级

真正的防御性调优：如何正确榨干 CPU 性能？

排查清单与同类问题速查

深入 RT 调度陷阱排查：SCHED_FIFO 引发的 RCU Stall 与 CPU 亲和性假死实战

故障现场：P99 飙升与节点失联

剥丝抽茧：谁霸占了 CPU？

为什么 SCHED_FIFO 结合绑核会引发系统假死？

破局与架构优化：防御性调度

1. 紧急止血：恢复 RT 节流

2. 长期重构：isolcpus + NOHZ_FULL + CFS

常见问题

深入 SCHED_FIFO 调度死锁排查：RT 优先级滥用引发的 RCU Stall 与 Node 假死实战

现场还原与死亡日志

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

消失的最后一道防线

极低延迟的正确实现姿势

排查清单与同类问题速查