Linux 内核实时调度与 PREEMPT_RT 深度实战

一、为什么实时性如此重要

在现代计算系统中，实时性早已不再是工业控制器的专利需求。从自动驾驶的传感器融合环路（<100μs），到 5G 基带的调度时延（<1ms），再到高频交易系统的订单响应（微秒级），再到云原生场景下的 QoS 保障，确定性延迟都是系统设计的核心约束。

需要纠正一个常见误区：实时系统 ≠ 快速系统。实时系统的核心是可预测性和截止期限保证（Deadline Guarantee）。一个平均响应 10μs 但偶尔抖动到 10ms 的系统，在实时场景下远不如一个稳定在 50μs 的系统。这也是为什么实时性讨论总是围绕着最坏情况执行时间（WCET）而非平均值展开。

我们将深入 Linux 内核实时子系统的三个层次：SCHED_FIFO/SCHED_RR/SCHED_DEADLINE 策略、PREEMPT_RT 补丁集的完整抢占模型改造、以及 cgroup v2 中 cpu.max/cpu.weight 的带宽控制机制。最终通过真实端到端延迟测试数据，给出生产级部署的最佳实践。

二、Linux 调度策略全景

Linux 内核的调度策略可以分为三大类，它们的优先级关系如下（数值越低，实际优先级越高）：

硬实时优先级	软实时/分时	空闲/批处理
SCHED_FIFO (1-99) SCHED_RR (1-99) SCHED_DEADLINE (0)	SCHED_NORMAL / CFS SCHED_BATCH SCHED_OTHER	SCHED_IDLE

2.1 SCHED_FIFO — 先到先服务的实时队列

SCHED_FIFO（First In First Out）是最基础的实时策略。一旦高优先级实时任务进入运行态，它会一直运行直到以下情形之一发生：

• 主动阻塞等待资源（mutex、I/O）
• 主动让出 CPU（sched_yield()）
• 更高优先级的实时任务就绪

关键特性：没有时间片概念。同一优先级内严格 FIFO 排队。这意味着一个编写拙劣的 SCHED_FIFO 任务可能永远霸占 CPU——这既是最大的保障，也是最大的风险。

#include <sched.h>
struct sched_param param = { .sched_priority = 80 };
if (sched_setscheduler(0, SCHED_FIFO, &param) == -1) {
    perror("sched_setscheduler failed");
    // 注意：设定实时优先级需要 CAP_SYS_NICE 能力
}

2.2 SCHED_RR — 带时间片的轮转

SCHED_RR（Round Robin）在 SCHED_FIFO 基础上引入了时间片分配。同一优先级的任务在耗尽时间片（默认 100ms，可通过 sched_rr_get_interval() 查询）后被强制轮转。对于需要多个同优先级实时任务"公平"共享 CPU 的场景，SCHED_RR 更安全。

2.3 SCHED_DEADLINE — 基于 EDF 的硬实时

SCHED_DEADLINE 是 Linux 3.14 引入的最强实时调度策略，基于Earliest Deadline First 算法，并结合Constant Bandwidth Server模型进行带宽隔离。

每个 DL 任务通过三个参数定义：

• Runtime（Q）：每次激活时允许消耗的 CPU 时间（纳秒）
• Deadline（D）：每次激活的截止期限（纳秒）
• Period（P）：激活周期（纳秒），通常 D ≤ P

CBS 的核心规则——不可越权：

• 任务的实际 deadline 不会早于其声明的 deadline
• 任务在其他模式下累积的 CPU 消耗不会影响其 DL 世界中的带宽
• 如果任务在同一 period 内用完了 runtime，它会被"节流"直到下一个 period

#include <linux/sched.h>
struct sched_attr attr = {
    .size = sizeof(attr),
    .sched_policy = SCHED_DEADLINE,
    .sched_flags = 0,
    .sched_nice = 0,
    .sched_priority = 0,  // DL不使用静态优先级
    .sched_runtime  =  20 * 1000 * 1000,  // 20ms
    .sched_deadline =  50 * 1000 * 1000,  // 50ms
    .sched_period   = 100 * 1000 * 1000,  // 100ms
};
syscall(__NR_sched_setattr, 0, &attr, 0);

准入控制：内核在 SCHED_DEADLINE 任务加入时执行全局 EDF 可调度性测试：

Σ(Qᵢ / Pᵢ) ≤ CPU 数量（多核全局调度下）

2.4 sched_setattr vs sched_setscheduler

sched_setscheduler() 只支持 FIFO/RR/OTHER 等传统策略，sched_setattr() 是 Linux 3.14+ 的统一调度属性接口，支持 SCHED_DEADLINE 以及 SCHED_FLAG_RESET_ON_FORK 等标志位。新代码应始终使用 sched_setattr。

三、优先级反转与解决方案

3.1 问题的本质

优先级反转（Priority Inversion）是实时系统中最经典的问题：

1. H（高优先级）和 L（低优先级）共享一个互斥锁
2. L 先获得锁并进入临界区
3. H 就绪并抢占 L，但尝试获取锁时被阻塞（Mutex Held by L）
4. M（中优先级，不持锁）此时就绪——由于优先级高于 L，它抢占了 L
5. L 被 M 阻塞而无法释放锁 ⇒ H 被间接无限期阻塞

这就是 1997 年火星探路者号重启事件的根本原因——NASA 的 VxWorks 系统也栽在了优先级反转上。

3.2 优先级继承（Priority Inheritance）

Linux 内核通过 PTHREAD_PRIO_INHERIT 属性实现。当 H 阻塞在 L 持有的锁上时，L 临时继承 H 的优先级，使其能快速执行完临界区并释放锁。

pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_INHERIT);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
pthread_mutex_init(&lock, &attr);

3.3 优先级天花板（Priority Ceiling）

PTHREAD_PRIO_PROTECT 方案：在锁初始化时就指定一个 ceiling 优先级。任何持有该锁的任务立即提升到 ceiling 优先级，无需等待高优先级任务阻塞。代价是可能过度提升，但彻底预防了反转链。

四、PREEMPT_RT — 将 Linux 变为实时内核

4.1 核心思路：减少不可抢占区域

标准 Linux 内核的抢占点有限——在内核空间执行时（中断处理、持有 spinlock、关闭抢占等），用户任务无法被抢占。PREEMPT_RT 的目标是把这些不可抢占区域降到最低。

中断后、spinlock、调度器这四个核心改造PREEMPT_RT ：

// 中断处理变为一个可抢占的 kthread irq_thread() { while (!kthread_should_stop()) { // 等待中断事件事件唤醒 // 如果此时更高优先级的实时用户任务就绪，当前 irq_thread 会被抢占 set_current_state(TASK_INTERRUPTIBLE); if (!irq_wakeup) schedule(); // === 抢占点 === } // 实际执行中断处理逻辑 my_irq_handler(dev); }

这意味着实时任务线程（优先级 80）现在可以抢占优先级仅 50 的中断处理线程——这是在标准内核中完全不可能的。

4.3 spinlock → rtmutex

RT 将内核中绝大多数 spinlock_t 替换为 rtmutex（基于 PI 的互斥锁）。原先持有自旋锁时关闭抢占的区域，现在变成了可睡眠、可被抢占的 rtmutex。

4.4 三种抢占模型对比

CONFIG_PREEMPT_NONE (服务器，最大化吞吐量)
CONFIG_PREEMPT_VOLUNTARY (桌面，自愿抢占点)
CONFIG_PREEMPT (低延迟桌面，基本抢占)
CONFIG_PREEMPT_RT (硬实时，完全抢占)

PREEMPT_RT 对系统延迟的影响（典型 x86-64 场景）：

• 标准 PREEMPT 内核：最大调度延迟 ~1-10ms（取决于负载和中断频率）
• PREEMPT_RT 内核：最大调度延迟 < 100μs（典型 ~20-50μs）

五、cgroup v2 CPU 带宽控制

在多租户/混合部署场景中，实时任务和业务任务共存时，需要通过 cgroup v2 的 CPU 控制器实现硬性的份额隔离。

5.1 cpu.max — 带宽硬上限

cpu.max 定义每个周期内允许使用的 CPU 时间（微秒）：

# /sys/fs/cgroup/rt-tasks/cpu.max
50000 100000
# = 每 100ms 周期内最多使用 50ms（即 0.5 个 CPU 核心）

超过上限后任务被节流（throttled）直到下一周期——无论其优先级多高。

5.2 cpu.weight — 相对份额

CFS 控制组之间的 CPU 竞争通过 cpu.weight（1-10000，默认 100）调节。例如：

• A：weight=100，B：weight=300 ⇒ 当 CPU 竞争时，A 获得 25%，B 获得 75%
• 这是 CFS 的份额分配，仅当 CPU 饱和时才生效

5.3 cpu.rt.max — 实时任务带宽限制

cgroup v2 通过 cpu.rt.max 限制组内实时任务的 CPU 占用，防止高优先级实时任务饿死整个系统：

# /sys/fs/cgroup/critical-rt/cpu.rt.max
95000 100000
# 该 cgroup 中 SCHED_FIFO/SCHED_RR 任务每 100ms 最多运行 95ms
# 保留 5ms 给 CFS 任务，防止系统完全卡死

5.4 cpuset — CPU 亲和性隔离

对于最严格的实时场景，应该结合 cpuset.cpus 将实时任务独占若干 CPU 核心：

# 隔离 CPU 2-3 核给内核使用（启动参数）
 isolcpus=2,3 nohz_full=2,3 rcu_nocbs=2,3

# cpuset 实时任务专用核
mkdir /sys/fs/cgroup/rt-cpus
echo "2-3" > /sys/fs/cgroup/rt-cpus/cpuset.cpus
echo "0" > /sys/fs/cgroup/rt-cpus/cpuset.mems  # NUMA 本地内存
echo $PID > /sys/fs/cgroup/rt-cpus/cgroup.procs

关键参数解读：

• nohz_full：关闭该核上的周期性 tick，避免时钟中断干扰实时任务
• rcu_nocbs：将 RCU callback 移出该核，避免回调处理引入抖动
• isolcpus：内核调度器不会将普通调度任务分配到隔离核（现代 kernel 已由 cpuset housekeeping 替代，但保持兼容）

六、NUMA 拓扑与调度器感知

在多路服务器场景下，NUMA 感知的实时调度至关重要。访问远程内存的延迟可达本地内存的 2-3 倍，这直接影响 WCET。

6.1 NUMA 关联调度

进程在 NUMA 节点间的迁移有三种触发方式：

1. Initial placement：进程首次创建时分配到父进程所在的 Node
2. AutoNUMA balancing：内核采样页面访问，周期性迁移内存和任务到访问最频繁的节点（numabalancing）
3. explicit migration：通过 mbind()、set_mempolicy() 或 numactl --cpunodebind 手动指定

6.2 实时任务的最佳实践

# 将实时任务绑定到 NUMA Node 0 的 CPU
numactl --cpunodebind=0 --membind=0 ./rt_worker

# 等价于通过 sched_setaffinity + mbind
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(0, &cpuset);  // CPU 0 (Node 0 上)
CPU_SET(1, &cpuset);  // CPU 1 (Node 0 上)
sched_setaffinity(0, sizeof(cpuset), &cpuset);

故障排查：查看当前 NUMA 调度统计：

$ numastat -p $PID

Per-node process memory usage (in bytes) for PID 1123:
           Node 0     Node 1     Total
----------- ---------- ---------- ----------
Anon       120000000   24000000  144000000        # 83% 在本地 Node
Mapped      10000000    2000000   12000000
 
# 查看 NUMA hinting faults
$ grep -r . /proc/$PID/numa_maps | head -5
7f2d00000000 default file=/usr/lib/libc.so.6 anon=204 mapped=204
 mappedpermit
7f2d01000000 default heap anon=1000 mapped=1000 maxN0=950 N1=50
  ← 1000 页中 50 页在 Node1 → 5% 远程访问

七、延迟测量与调优实战

7.1 cyclictest — 实时延迟金标准

cyclictest 是 rt-tests 工具集中的实时延迟测量工具，通过周期性唤醒测量调度抖动：

# 安装
 apt install rt-tests  # Debian/Ubuntu
 dnf install rt-tests  # Fedora/RHEL9+

# 基准测量：5 线程 SCHED_FIFO 优先级 80，50000 次循环
 cyclictest --duration=60 --priority=80 --threads=5 \
   --interval=1000 --loop=50000 --policy=fifo \
   --affinity=0x0F --smp --histogram=1000 --quiet

# 输出解读：
# T: 0     序号线程
# Count: 60000        // 完成 60k 次循环
# Avg: 23  us         // 平均延迟 23 微秒
# Min: 12  us         // 最小
# Max: 89  us         // 最大最坏情况——关键指标！
# Act: 23  us         // 当前

7.2 端到端延迟测试

cyclictest 测量的只是内核调度延迟。真实系统的端到端（E2E）延迟应该用 ftrace + latency_hist 或 LTTng：

# 通过 debugfs 查看调度延迟直方图
 mount -t debugfs none /sys/kernel/debug
 echo 0 > /sys/kernel/debug/tracing/tracing_on
 echo "sched_switch sched_wakeup preempt_enable" > /sys/kernel/debug/tracing/set_event
 echo 1 > /sys/kernel/debug/tracing/options/latency-format
 echo 1 > /sys/kernel/debug/tracing/tracing_on
 # ... 运行 workload ...
 cat /sys/kernel/debug/tracing/trace | head -50

# 通过 perf 统计上下文切换
 perf stat -e 'sched:sched_switch,sched:sched_wakeup' -p $PID sleep 10

7.3 关键 sysctl 调优

# 检查 C-state 深度导致的最大休眠唤醒延迟 cat /sys/devices/system/cpu/cpu0/cpuidle/state*/latency # state0(C0): 0 state1(C1): 1 state2(C6): 80 state7(C10): 800 μs # 关闭深度 C-state（实时场景必须） 在 BIOS 中禁用 C6/C7/C8... 状态 或内核参数：processor.max_cstate=1 intel_idle.max_cstate=1 # 固定频率（禁止动态调频） echo "performance" > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor # 或 intel_pstate=disable 使用 acpi-cpufreq + performance

八、生产级部署最佳实践

8.1 配置决策树

 延迟要求 ≤ 50μs？
  是 → PREEMPT_RT 内核 + SCHED_DEADLINE + CPU 独占 + 禁用 C/P state
  否 → 延迟 ≤ 10ms？
    是 → PREEMPT_RT 内核或 PREEMPT 内核 + SCHED_FIFO + cpuset 绑核
    否 → 延迟可接受百 ms 级？
      是 → 标准 CFS + cgroup v2 cpu.weight 权重
      否 → 这不是实时问题，而是吞吐问题

是否需要 CPU 独占？
 是 → 配置 isolcpus + nohz_full + rcu_nocbs，taskset 绑核
 否 → cgroup v2 cpu.max 限制，与业务任务共存

8.2 常见陷阱清单

1. NUMA 远程内存访问：实时堆分配使用 mbind(MPOL_BIND) 绑定本地 Node
2. Transparent Huge Pages：madvise 模式而非 always，避免 khugepaged 引入抖动
3. Page Faults：启动前 mlockall(MCL_CURRENT | MCL_FUTURE) 锁定所有内存，避免运行时换入
4. syscall 开销：vDSO 替代的时钟调用（clock_gettime）vs 通过 RDTSC 指令
5. PMU 中断：perf 监控带来的 NMI 中断可设置 kernel.perf_event_max_sample_rate=1 或关闭
6. IOMMU：DMA重映射配置不当可能引入延迟抖动，实时场景需测试
7. CPU SMT：超线程上的 sibling core 共享 L1 cache 和 execution unit，实时任务最好关闭 SMT 或避开 sibling 核

8.3 验证清单

# 1. 确认 PREEMPT_RT 模式
 uname -v | grep -i preempt
 # #1 SMP PREEMPT_RT ...

# 2. 确认 CPU 隔离设置
 cat /sys/devices/system/cpu/isolated
 # 2-3 ← 2-3 核被隔离

# 3. 确认实时任务运行在隔离核
 taskset -p $PID
 # pid 12345's current affinity mask: c  ← 0b1100 = CPU 2,3

# 4. 确认无深度 C-state
 cat /sys/devices/system/cpu/cpu2/cpuidle/state*/name
 # POLL（仅运行态，无深度休眠）

# 5. 最终 cyclictest 压测
 cyclictest --duration=300 --priority=99 --threads=1 \
   --interval=500 --loop=1000000 --policy=fifo \
   --affinity=0x04 --mlockall --smp --histogram=500
 # 要求：Max Latency < 目标阈值（如 50μs）

九、总结

Linux 实时子系统是一个从用户态策略（SCHED_FIFO/RR/DEADLINE）到内核态抢占模型（PREEMPT_RT），再到资源隔离（cgroup v2/cpuset）和硬件调优（C-state/P-state/SMT）的完整体系。

关键认知转变：实时性不是"快"，而是"确定"。追求极致的确定性意味着你必须放弃部分吞吐量优化——专属核牺牲了利用率，禁用 C-state 牺牲了功耗，关闭超线程牺牲了吞吐。这些取舍需要根据具体场景权衡。

目前 PREEMPT_RT 补丁的大部分内容（线程化中断、rtmutex、高精度定时器）已经合入主线 Linux 6.x，剩余 PREEMPT_RT 补丁（主要是 printk 线程化、部分驱动适配）正在持续推进中。未来数年内，Linux 主线内核将原生支持硬实时抢占，这对自动驾驶、工业控制和媒体制作领域意义重大。