从硬实时到 Linux：PREEMPT_RT 的工程实践与延迟确定性架构

1. 为什么我们需要 "实时" Linux

工业机械臂的控制周期是 250µs——这意味着每 250µs 必须完成一次位置采样、PID 计算和 PWM 输出。如果某次延迟到了 2ms，机械臂就可能抖动甚至失控。传统的 Linux 内核在 CONFIG_PREEMPT_VOLUNTARY 配置下，一个系统调用的延迟可能在毫秒级抖动，根本无法满足这类硬实时需求。

PREEMPT_RT（Real-Time Patch）正是为了解决这个问题而生。它通过将 Linux 内核中那些可能导致长时间关中断的区域转化为可抢占的代码路径，使得内核态的最高优先级任务延迟可以被控制在 10-100µs 级别。自 5.15 开始进入主线开发，到 6.12 LTS 已经完全合并进主线内核，不再需要额外打补丁。

本文将从内核配置、中断线程化、实时锁机制、延迟测量到实际部署调优，系统讲解 PREEMPT_RT 在生产环境中的工程实践。

2. 内核配置：三档抢占模型的选择

2.1 抢占模型对比

Linux 内核提供三档服务器/桌面抢占模型和一档实时模型：

配置	关抢占区域	典型延迟	适用场景
CONFIG_PREEMPT_NONE	几乎所有内核代码	不确定	吞吐优先的 HPC
CONFIG_PREEMPT_VOLUNTARY	显式 cond_resched 点	1-10ms	通用服务器
CONFIG_PREEMPT	大部分内核区可抢占	0.5-2ms	桌面/交互系统
CONFIG_PREEMPT_RT	几乎全路径可抢占 + 中断线程化	10-100µs	工业控制/电信

2.2 RT 内核关键配置选项

选择 CONFIG_PREEMPT_RT 后，以下配置会联动启用或需要关注：

CONFIG_PREEMPT_RT=y              # 启用完全可抢占实时内核
CONFIG_HZ_1000=y                 # 1000Hz tick，更精细调度
CONFIG_HIGH_RES_TIMERS=y         # hrtimer 高精度定时器
CONFIG_NO_HZ_FULL=y              # 全动态 tick，减少时钟中断干扰
CONFIG_CPU_ISOLATION=y           # CPU 隔离（isolcpus）
CONFIG_RT_GROUP_SCHED=y          # RT 任务组调度配额

生产环境中一个典型陷阱：启用 CONFIG_HZ_1000 会带来约 1-3% 的吞吐开销，但如果使用 CONFIG_NO_HZ_FULL，可以让绑核的 RT 任务所在的 CPU 完全跳过周期 tick（tickless），将延迟抖动降低一个数量级。

3. 中断线程化：RT 的根基

3.1 原理

传统 Linux 中中断处理程序（ISR）在关中断上下文执行，可以抢占一切任务——包括最高优先级的 RT 任务。PREEMPT_RT 将几乎所有硬件中断的处理移到线程上下文（irq_thread），赋予其实时优先级（默认 50）。此时中断处理程序也可以被更高优先级的任务抢占，从根本上解决了中断风暴导致的延迟不确定性。

3.2 中断线程优先级管理

# 查看当前中断线程的优先级
ps -eo pid,class,rtprio,comm | grep irq

# 输出示例：
# PID  CLS RTPRIO COMMAND
#  45  FF     50 irq/120-aerdrv     -- PCIe AER 中断
#  67  FF     50 irq/88-eth0        -- 网卡中断

# 降低网卡中断优先级（让机械臂控制线程优先）
chrt -f -p 45 67       # 将网卡中断线程降为优先级 45
chrt -f -p 80 1234     # 机械臂控制线程优先级 80（最高）

关键原则：RT 系统使用 SCHED_FIFO，优先级数值越大越高（1-99）。中断线程默认 50，所以用户态 RT 任务应设在 51-99 之间。

3.3 threadirqs 启动参数

对于不使用 PREEMPT_RT 内核但仍需要中断线程化的场景，可以添加启动参数：

threadirqs

这会强制所有 IRQ 走线程（但不等同于 CONFIG_PREEMPT_RT 的完整可抢占语义）。

4. 实时锁机制：从自旋锁到 rtmutex

4.1 自旋锁的 RT 化改造

在 PREEMPT_RT 内核中，spinlock_t 被替换为 rt_spinlock，其底层实现为 rt_mutex——即自旋锁在获取不到时会阻塞并让出 CPU，而不是忙等待。这意味着：

• 持有锁的低优先级任务running态被锁阻塞时，持有锁的高优先级任务可以立即获取锁（通过优先级继承）
• 最高优先级任务不会被低优先级任务持有的自旋锁卡死

4.2 优先级继承（Priority Inheritance）

经典场景：

H (prio 80): 尝试获取 lock_A → 被阻塞
M (prio 60): 无关任务，正在运行
L (prio 40): 持有 lock_A → 被 M 抢占

在传统非继承锁下，H 必须等 L 释放锁，但 L 又被 M 抢占 → H 被 M 间接阻塞（优先级反转）。

优先级继承机制使 L 临时提升到 H 的优先级（80），迅速释放锁后恢复。代码层面只需正确使用 rt_mutex：

#include <linux/mutex.h>
#include <linux/sched.h>

struct rt_mutex lock;

void critical_section(void)
{
    rt_mutex_lock(&lock);     // 支持优先级继承
    // ... 访问共享资源 ...
    rt_mutex_unlock(&lock);
}

4.3 rwlock 与 RCU 的注意事项

• rwlock_t 在 RT 下也是 sleeping lock，持有读锁的读者不会阻塞高优先级写者太久（但有 writer starvation 风险）
• RCU 在 RT 内核中工作正常，是读多写少场景的首选
• raw_spinlock_t 保持真正的自旋语义，仅用于极少场景（如调度器核心、板上中断控制器寄存器访问），使用时需极度谨慎

5. 延迟测量：cyclictest 实战

5.1 cyclictest 工作原理

cyclictest 是 RT 系统的标准延迟测试工具。原理：创建一个周期性的 SCHED_FIFO 高优先级线程，每个周期（如 1ms）醒来后将当前时间戳与预期时间戳相减——差值就是调度延迟。

5.2 典型测试命令

# 基础测试：单线程 1ms 周期，运行 100 万个周期
cyclictest -m -S -p 80 -i 200 -l 1000000
# -m: mlockall 防止页面换出
# -S: 单 CPU 模式（不跨核迁移）
# -p 80: SCHED_FIFO 优先级 80
# -i 200: 200µs 周期（即 5KHz 采样）
# -l: 循环次数

# 多线程压力测试（4 核 RT 应用模拟）
cyclictest -a 0-3 -t 4 -p 80 -i 100 -h 400 -D 1h
# -a: 绑定 CPU affinity
# -t 4: 4 个线程
# -i 100: 100µs 周期
# -h 400: 直方图最大 400µs
# -D 1h: 运行 1 小时

5.3 延迟来源解读

cyclictest 输出的直方图中，超出预期的峰值通常来自以下几个来源：

[直方图分析]
0-10µs:     正常调度窗口（NMIs、SMIs 不可抢占时偶尔进入）
10-50µs:    典型 RT 延迟范围
50-200µs:   通常是 SMEP/SMAP 切换、TLB flush、page fault
200-500µs:  通常是未隔离的 kernel workqueue、ACPI 事件、固件活动
>500µs:     CPU 隔离失效、NUMA 远程内存访问、PCIe FLR（Function Level Reset）

常见大延迟来源排查：

# 检查 SMI（System Management Interrupt）——不可屏蔽，可从 RT 任务偷走 100+µs
grep -i smi /proc/interrupts
# 如果存在 SMI 中断，需要在 BIOS 中禁用 ME/AMT 或降低 SMI 频率

# 检查未隔离的 workqueue
cat /sys/devices/virtual/workqueue/cpumask
# 应该排除 RT 任务使用的核心

# 检查 timer_migration
cat /proc/sys/kernel/timer_migration
# RT 下设为 0（禁止低优先级 timer 迁移到 RT 核）

6. 生产部署：CPU 隔离与调度策略

6.1 CPU 隔离三步法

生产环境要让 RT 任务获得确定性延迟，CPU 隔离是第一步：

第一步：GRUB 启动参数隔离核心

# /etc/default/grub
GRUB_CMDLINE_LINUX="isolcpus=4,5,6,7 nohz_full=4,5,6,7 rcu_nocbs=4,5,6,7"

# isolcpus: 将 CPU 4-7 从调度器中隔离，不分配给普通进程
# nohz_full: CPU 4-7 启用 full tickless，停止周期时钟中断
# rcu_nocbs: RCU callback 不在 CPU 4-7 上执行，进一步减少中断

第二步：设置 IRQ affinity

# 将所有硬件中断路由到非 RT 核心（0-3）
echo 0f > /proc/irq/120/smp_affinity    # PCIe 中断 → CPU 0-3
echo 0f > /proc/irq/88/smp_affinity     # 网卡中断 → CPU 0-3

# 或者使用 irqbalance 并配置 banned_cpu
cat /etc/sysconfig/irqbalance
IRQBALANCE_BANNED_CPUS=000000f0        # 禁止 irqbalance 分配中断到 CPU 4-7

第三步：将 RT 任务绑核

// 程序中设置 CPU affinity 到隔离核
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(4, &cpuset);    // 使用隔离核心 4

pthread_setaffinity_np(pthread_self(), sizeof(cpuset), &cpuset);

// 设置实时调度策略
struct sched_param param = { .sched_priority = 80 };
pthread_setschedparam(pthread_self(), SCHED_FIFO, &param); mlockall(MCL_CURRENT|MCL_FUTURE);   // 锁定内存

6.2 内存锁定与预分配

RT 任务严禁触发 page fault：

#include <sys/mman.h>

int main()
{
    mlockall(MCL_CURRENT | MCL_FUTURE);  // 锁定当前和未来所有内存

    // 或者对特定内存区域使用 Hugepage
    void *buf = mmap(NULL, 2*1024*1024,
                     PROT_READ | PROT_WRITE,
                     MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB | MAP_HUGE_2MB,
                     -1, 0);
}

配置 Hugepage（内核启动参数）：

default_hugepagesz=2M hugepagesz=2M hugepages=64

7. RT 性能分析工具链

7.1 ftrace 下的 wakeup_rt 分析器

# 启用 wakeup_rt tracer（最常用于 RT 延迟分析）
echo wakeup_rt > /sys/kernel/debug/tracing/current_tracer
echo 1 > /sys/kernel/debug/tracing/tracing_on

# 触发延迟后查看 trace
cat /sys/kernel/debug/tracing/trace | head -80

# 输出显示了从 wake_up_process 到实际执行的完整调用栈
# 可以看到延迟到底消耗在哪个锁、哪个中断处理上

7.2 LRTB（Linux Real-Time Benchmarking）

完整评估 RT 系统的测试矩阵：

测试项	工具	指标
调度延迟	cyclictest	min/max/avg, 直方图分布
上下文切换	lmbench ctxswitch	单次 ctx switch 耗时
中断延迟	hwlatdetect	硬件引入的延迟
I/O 确定性	iostat + RT task	I/O 完成时间抖动
网络收发	pktgen + RT task	收包端到端延迟

# hwlatdetect：测量硬件/固件引起的延迟（绕过 OS）
hwlatdetect --duration=60 --threshold=20
# 如果测到 >20µs 的 gap，说明存在 SMI/BIOS activity
# 这是 RT 方案的硬件天花板

7.3 实时事件的 BPF 追踪

# 使用 bpftrace 追踪 RT 任务被抢占的时间点
bpftrace -e '
kretprobe:try_to_wake_up /retval == 0/ {
    $task = (struct task_struct *)arg0;
    if ($task->prio < 100) {
        @missed_ns[comm, cpu] = nsecs;
    }
}'

8. PREEMPT_RT 在实际产品中的典型架构

以工业视觉检测系统为例，完整架构如下：

┌──────────────────────────────────────────────────────────┐
│  CPU 0-3: 非 RT 域 (Linux 普通进程)                        │
│  ┌─────────┐ ┌──────────┐ ┌──────────┐ ┌─────────────┐   │
│  │ Web UI  │ │ Database │ │ Logging  │ │ ML Inference│   │
│  └─────────┘ └──────────┘ └──────────┘ └─────────────┘   │
│  ↑ 中断全部路由到这里          ↓ 周期性 RT 指令              │
├──────────────────────────────────────────────────────────┤
│  CPU 4-7: RT 域 (isolcpus + nohz_full)                    │
│  ┌─────────────┐ ┌──────────────┐ ┌───────────────────┐  │
│  │ 运动控制    │ │ 图像采集硬件 │ │ EtherCAT 主站     │  │
│  │ PRI 80/1kHz │ │ PRI 75/4kHz  │ │ PRI 70/2kHz      │  │
│  └─────────────┘ └──────────────┘ └───────────────────┘  │
│  延迟预算: <50µs (P99.9)                                  │
├──────────────────────────────────────────────────────────┤
│  共享内存（无锁 Ring Buffer）：RT 域 ←→ 非 RT 域通信         │
└──────────────────────────────────────────────────────────┘

关键设计要点：

1. RT 域与非 RT 域通过无锁环形缓冲区（Ring Buffer）通信——RT 侧只做"哨兵模式"读取，非 RT 侧负责数据处理和存储
2. RT 域绝不做内存分配、磁盘 I/O、网络收发
3. 看门狗：监控 RT 周期是否超限，超限立即进入安全状态
4. 降级策略：视觉检测超时未返回时，控制流使用的是上一次的有效结果

9. 常见陷阱与解决方案

9.1 打印输出是 RT 任务的杀手

# 打印比你想的慢得多！
printk() 平均延迟:   ~30-100µs（console 输出）
printk() 仅缓冲:      ~1-3µs（仅 ring buffer）

# 解决方案：RT 任务使用 trylock 日志
printk_deferred("RT task tick: %llu ns\n", tsc);
# 或使用 ftrace ring buffer（zero-copy，<1µs）

9.2 PCIe 的设备级复位 (FLR)

某些 PCIe 网卡驱动在 reset 时执行 FLR（Function Level Reset），会阻塞所有 PCIe 配置空间访问长达 10-100ms。这在 RT 环境中是致命的。

# 方案1：驱动层面开 quirk 跳过
echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset_method
# 方案2：使用 VFIO-PCI 接管后通过用户态驱动控制

9.3 时钟源选择

# 查看可用时钟源
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
# 典型输出: tsc hpet acpi_pm

# 强制使用 TSC（最快，跨核同步需稳定 RT-Skew）
echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource

# TSC 校准检查
dmesg | grep -i tsc
# 期望输出: "clocksource: Switched to clocksource tsc"
# 警告输出: "tsc: Marking TSC unstable due to check"

9.4 NUMA 远程内存访问

RT 任务若分配到的内存 page 在远端 NUMA 节点，跨 socket 访问延迟（~150-300ns）相比本地（~70-80ns）翻倍，可能带来确定性抖动。

// RT 任务启动时绑定 NUMA 节点
#include <numa.h>
numa_run_on_node(cpu_to_node(4));  // 绑在 CPU 4 的同 NUMA 节点

10. 总结：RT 系统实施的检查清单

□ 启用 CONFIG_PREEMPT_RT 内核 (≥6.12 LTS)
□ 配置 HZ_1000 + NO_HZ_FULL
□ isolcpus + rcu_nocbs 隔离 RT 核心
□ 所有硬件中断路由到非 RT 核
□ IRQ affinity: RT 核仅接收特定中断
□ RT 任务 mlockall(MCL_CURRENT|MCL_FUTURE)
□ 使用 Hugepage (2MB) 减少 TLB miss
□ cyclictest 验证 P99.9 延迟在目标预算内
□ 部署 wakeup_rt tracer 持续监控
□ 禁用 CPU 变频（cpufreq performance governor）
□ BIOS 禁用 C-states > C1, disable SMI, disable Turbo（可选）

PREEMPT_RT 不是银弹——它解决的是"确定性"问题而非"低延迟"。在正确配置的 RT 系统上，你得到的是一个可预测的延迟上限（例如 P99.9 = 80µs），而非极致的最快速度。正是这种确定性，让 Linux 从通用操作系统走进了工业控制、电信基站和自动驾驶的领域。

---

测试环境：Linux 6.12.1-rt5, AMD EPYC 7513, RT 域 4 核 @ 3.6GHz fixed, cyclictest 8h 运行，P99.9 = 34µs。