4. PREEMPT_RT核心机制

在机器人实时控制中，控制周期通常要求在 1 ms 甚至 250 μs 内完成一次“采样—计算—输出”的闭环。标准 Linux 内核为了追求吞吐量，在临界区、中断处理和锁竞争上会引入不可预测的延迟。PREEMPT_RT 补丁通过五项核心机制，把 Linux 改造成可预测的硬实时内核：完全抢占内核、优先级继承、自旋锁转为可睡眠锁、中断线程化、高精度定时器。理解这五项机制，是判断一个机器人控制器能否稳定运行在实时约束下的基础。

一、完全抢占内核：让高优先级任务随时拿到 CPU

标准 Linux 内核在进入系统调用、中断处理或持有自旋锁时，会关闭抢占，形成一段“不可抢占窗口”。如果机器人控制任务恰好在这段时间被唤醒，就必须等待窗口结束，延迟可能达到数百微秒甚至毫秒级。PREEMPT_RT 将内核中绝大部分不可抢占区域改为可抢占，包括中断处理、软中断、自旋锁临界区等。其核心思想是：只要不破坏数据一致性，内核代码随时可以被更高优先级的任务打断。

配置上，内核需要开启 CONFIG_PREEMPT_RT，并配合 CONFIG_PREEMPTION、CONFIG_PREEMPT_RT 等选项。编译后可通过以下命令确认实时抢占已生效：

uname -a
# 输出中应包含 PREEMPT_RT 字样
cat /sys/kernel/realtime
# 返回 1 表示实时内核已启用

二、优先级继承：解决优先级反转的经典手段

优先级反转是实时系统中最危险的隐患之一：高优先级任务等待一个被低优先级任务持有的锁，而低优先级任务又被中优先级任务抢占，导致高优先级任务被无限期延迟。PREEMPT_RT 使用 RT Mutex 实现优先级继承：当高优先级任务阻塞在某个锁上时，持有该锁的低优先级任务会临时继承高优先级任务的优先级，从而尽快执行完临界区并释放锁。

在机器人控制中，典型场景是：控制线程（优先级 80）需要读取由日志线程（优先级 20）持有的共享数据锁。若没有优先级继承，日志线程可能被其他普通任务抢占，控制线程被迫等待。启用 PI Mutex 后，日志线程临时提升到 80，快速完成写入并释放锁，控制线程的阻塞时间被压缩到微秒级。

三、自旋锁转为可睡眠锁：减少忙等待与不可抢占窗口

标准内核中的 spinlock 在等待时会忙等待并关闭抢占，这在实时场景下非常不利。PREEMPT_RT 将大部分 spinlock_t 转换为基于 RT Mutex 的可睡眠锁：当锁被占用时，等待者不再自旋，而是进入睡眠并让出 CPU，由调度器选择其他任务运行。这样既减少了 CPU 空转，也消除了“持锁期间不可抢占”的长窗口。

需要注意的是，并非所有自旋锁都能睡眠。在原子上下文（如硬中断处理程序）中，仍然需要使用原始自旋锁。PREEMPT_RT 通过 raw_spinlock_t 保留真正不可睡眠的锁，其余则转为可睡眠版本。驱动开发者需要根据上下文选择正确的锁类型。

锁类型	标准内核行为	PREEMPT_RT 行为	适用场景
spinlock_t	忙等待，关抢占	转为可睡眠 RT Mutex	进程上下文、可睡眠区域
raw_spinlock_t	忙等待，关抢占	保持忙等待，关抢占	硬中断、原子上下文
mutex	可睡眠	支持优先级继承	进程上下文共享资源
rt_mutex	不存在	可睡眠 + 优先级继承	实时任务间同步

四、中断线程化：把中断处理变成可调度任务

硬中断处理程序运行在最高优先级，会打断任何任务，包括机器人控制线程。PREEMPT_RT 将大部分中断处理程序线程化：中断到来时，内核只做最少的硬件确认工作，然后唤醒一个内核线程来执行实际处理逻辑。这个线程具有可配置的优先级，可以被更高优先级的控制任务抢占，也可以被调度器合理安排。

在机器人系统中，这意味着电机编码器中断、CAN 总线接收中断等不再直接打断控制循环，而是由中断线程在合适时机处理。控制线程的周期抖动因此显著降低。可以通过以下命令查看中断线程及其优先级：

ps -eLo pid,tid,cls,rtprio,comm | grep irq
# 典型输出：
# 1234  1234  FF  50  irq/45-eth0
# 1235  1235  FF  50  irq/46-can0

五、高精度定时器：纳秒级周期触发

标准 Linux 的定时器精度受限于 HZ 和 jiffies，通常为 1 ms 或 4 ms。对于需要 250 μs 控制周期的机器人关节伺服，这远远不够。PREEMPT_RT 引入 hrtimer（高精度定时器），基于硬件时钟源提供纳秒级分辨率，并支持高精度模式下的动态 tick，避免周期性 tick 带来的额外延迟。

用户空间可通过 clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, ...) 实现绝对时间睡眠，避免累积误差。典型控制循环如下：

struct timespec next;
clock_gettime(CLOCK_MONOTONIC, &next);
while (running) {
    next.tv_nsec += 1000000; // 1 ms 周期
    if (next.tv_nsec >= 1000000000) {
        next.tv_nsec -= 1000000000;
        next.tv_sec++;
    }
    clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &next, NULL);
    control_step();
}

六、案例与复盘：从 800 μs 抖动到 30 μs

某六轴协作机器人控制器最初运行标准 Linux，控制周期 1 ms，实测最坏抖动约 800 μs，导致关节在高速运动时出现轻微振动。排查发现三个问题：网卡中断直接打断控制线程、日志线程持有互斥锁导致优先级反转、定时器精度不足。迁移到 PREEMPT_RT 后，采取以下措施：

• 开启 CONFIG_PREEMPT_RT，确认 /sys/kernel/realtime 为 1；
• 控制线程设置为 SCHED_FIFO，优先级 80，并锁定内存 mlockall(MCL_CURRENT | MCL_FUTURE)；
• 日志互斥锁启用 PTHREAD_PRIO_INHERIT；
• 网卡中断线程优先级调整为 60，低于控制线程；
• 使用 clock_nanosleep 绝对时间睡眠替代 usleep。

优化后，最坏抖动降至约 30 μs，控制周期稳定在 1 ms ± 5%，关节振动消失。复盘时需注意两个误区：一是认为“打了 RT 补丁就万事大吉”，实际上用户空间任务优先级、内存锁定、锁协议同样关键；二是把所有中断线程优先级都设得过高，反而会抢占控制线程。正确的做法是让控制线程拥有最高优先级，中断线程次之，普通任务最低。

总结来看，PREEMPT_RT 的五项机制分别从抢占、同步、锁、中断和定时五个维度消除延迟源。它们不是孤立选项，而是一套协同工作的实时化改造：完全抢占让高优先级任务及时运行，优先级继承防止阻塞，可睡眠锁减少不可抢占窗口，中断线程化把异步事件纳入调度，高精度定时器提供精确的时间基准。只有五项机制同时正确配置，机器人实时控制才能获得稳定、可预测的微秒级响应。