解析 ‘PREEMPT_RT’ 补丁：如何将通用 Linux 改造为具备确定性响应的硬实时内核？ - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位同仁，各位对系统编程与实时控制充满热情的工程师们：

欢迎来到今天的讲座，我们将深入探讨一个在工业控制、航空航天、医疗设备以及高性能计算领域至关重要的技术——如何将我们熟悉的通用 Linux 操作系统改造为具备确定性响应的硬实时内核。今天的主角，正是 Linux 内核的 PREEMPT_RT 补丁。

开场：硬实时系统的挑战与Linux的不足

在计算机科学的广阔天地中，存在着一类对时间响应有着极其严苛要求的系统，我们称之为实时系统。实时系统根据其对时间约束的严格程度，又分为软实时、固实时和硬实时。

软实时系统 (Soft Real-time Systems)：允许偶尔错过截止时间，例如多媒体播放、网页服务器。性能下降但系统不会崩溃。
固实时系统 (Firm Real-time Systems)：错过截止时间会降低系统质量，但不会导致灾难性后果，例如在线交易系统。
硬实时系统 (Hard Real-time Systems)：必须在严格的截止时间前完成任务，任何一次延迟都可能导致系统故障，甚至灾难性后果。例如工业机器人控制、飞行控制系统、医疗生命支持设备。

通用 Linux 内核以其强大的功能、灵活性和广泛的硬件支持而闻傲。然而，它在设计之初，主要目标是追求高吞吐量和平均响应时间，而不是最坏情况执行时间（WCET）的确定性。这使得通用 Linux 在面对硬实时应用时显得力不从心。其主要不足体现在：

高延迟与不确定性：通用 Linux 内核在执行关键操作时，如中断处理、内核锁竞争、系统调用等，可能会禁用抢占（preemption）或长时间运行不可中断的代码段。这会导致高优先级的实时任务被低优先级任务或内核自身操作阻塞，从而产生不可预测的延迟。
中断处理机制：传统 Linux 的中断处理分为上半部（hard IRQ）和下半部（soft IRQ，如 tasklet, workqueue）。上半部在禁用中断的情况下运行，不可抢占，这引入了显著的延迟抖动（jitter）。
锁机制：内核中的自旋锁（spinlock）在多处理器系统上用于保护共享数据。当一个任务尝试获取被占用的自旋锁时，它会忙等待（busy-waiting），直到锁被释放。如果持有锁的是一个低优先级任务，而一个高优先级实时任务需要该锁，就会发生经典的“优先级反转”（priority inversion）问题，高优先级任务被低优先级任务无限期阻塞。
调度器：虽然 Linux 提供了 SCHED_FIFO 和 SCHED_RR 等实时调度策略，但内核自身的非抢占区域和锁机制的限制，使得这些策略的实际效果大打折扣。
内存管理：通用 Linux 倾向于使用虚拟内存和页面置换，这可能导致实时任务在关键时刻因页面错误（page fault）而产生不可预测的延迟。

正是为了解决这些挑战，社区开发了 PREEMPT_RT（Preemptible Real-Time）补丁。它旨在通过一系列深入的内核改造，将通用 Linux 转化为一个能够满足硬实时需求的操作系统。

PREEMPT_RT的核心理念：一切皆可抢占

PREEMPT_RT 的核心哲学可以概括为一句话：“一切皆可抢占 (Everything is Preemptible)”。这意味着，无论是内核代码的执行、中断处理，还是内核锁的获取，都应尽可能地允许更高优先级的任务抢占。通过最大程度地消除内核中的非抢占区域和优先级反转问题，PREEMPT_RT 力求将最坏情况执行时间降至最低，从而实现确定性的任务响应。

为了实现这一目标，PREEMPT_RT 对 Linux 内核的多个核心组件进行了根本性的修改。我们将逐一深入探讨这些关键的改造。

深度解析PREEMPT_RT的关键改造

1. 中断线程化：IRQ处理的革命

在通用 Linux 内核中，中断处理程序（Interrupt Service Routine, ISR）通常在中断上下文（interrupt context）中运行。这意味着它们在执行期间会禁用当前 CPU 的中断，且是不可抢占的。一个长时间运行的 ISR 会阻塞所有其他任务，包括高优先级的实时任务和更低优先级的中断，从而导致严重的延迟。

传统中断的痛点：

不可抢占：ISR 一旦开始执行，就必须完成，期间不能被任何其他任务或更高优先级的中断抢占（除非是更高硬件优先级的中断）。
禁用中断：ISR 在执行时通常会禁用当前 CPU 上的其他中断，这进一步增加了延迟。
优先级反转：如果一个低优先级的外设产生了一个中断，其 ISR 正在执行，而此时一个高优先级实时任务需要运行，它必须等待 ISR 完成。

PREEMPT_RT 如何将中断处理程序变为可抢占线程：

PREEMPT_RT 最激进也最有效的改造之一，就是将绝大多数的硬件中断处理程序“线程化”。这意味着，原本在中断上下文中直接执行的 ISR，现在被封装成独立的内核线程。这些中断线程（IRQ threads）具有以下特性：

可抢占：它们现在是普通的内核线程，可以被调度器调度，并且可以被更高优先级的实时任务抢占。
优先级可控：每个中断线程都可以被赋予一个优先级，我们可以根据中断的重要性来配置它们。通常，高优先级的中断（如定时器中断）会被赋予更高的实时优先级。
允许中断：中断线程在执行时不再禁用中断，从而允许其他中断正常处理。

机制详解：

当一个硬件中断发生时，PREEMPT_RT 内核的 handle_irq_event() 函数（或类似逻辑）会迅速完成最低限度的硬件寄存器操作，然后唤醒相应的中断线程。实际的中断处理逻辑，包括上半部和下半部的职责，都在这个中断线程中执行。

改造前后对比表格：

特性	通用 Linux 内核	PREEMPT_RT 内核
执行上下文	中断上下文（硬件中断直接调用 ISR）	线程上下文（硬件中断唤醒 IRQ 线程）
可抢占性	不可抢占	可抢占
优先级	硬件优先级决定，不可由软件配置	可由软件配置（`SCHED_FIFO` 或 `SCHED_RR`）
禁用中断	ISR 执行期间禁用当前 CPU 中断	IRQ 线程执行期间允许中断
延迟抖动	高，受 ISR 执行时间影响	低，IRQ 线程可被更高优先级任务抢占

代码示例：中断线程化后的处理流程（概念性，非实际内核代码）

在 PREEMPT_RT 中，一个中断处理程序的注册看起来与通用 Linux 类似，但底层机制已发生改变。当 request_irq() 被调用时，如果 CONFIG_PREEMPT_RT_FULL 启用，内核会为该中断创建一个特殊的内核线程。

假设我们有一个中断处理函数 my_interrupt_handler：

// 通用 Linux 概念
irqreturn_t my_interrupt_handler(int irq, void *dev_id) {
    // 短时间、快速完成的工作 (上半部)
    // ...

    // 调度下半部工作 (例如 tasklet_schedule(), schedule_work())
    // ...

    return IRQ_HANDLED;
}

// 在 PREEMPT_RT 中，这个函数会被封装进一个线程
// 实际的中断发生时，会有一个很短的 stub 唤醒 irq/N 线程
// irq/N 线程内部会调用 my_interrupt_handler
// 这个 irq/N 线程是可抢占的，并且可以设置其优先级

// 注册中断时：
// request_irq(IRQ_NUM, my_interrupt_handler, IRQF_SHARED, "my_device", &my_dev);

在 PREEMPT_RT 内部，request_irq 函数会检查 CONFIG_PREEMPT_RT_FULL 宏。如果启用，它会为这个中断创建一个内核线程，命名通常是 irq/N-device_name，其中 N 是中断号。这个线程的调度策略默认为 SCHED_FIFO，优先级可以通过 /proc/irq/N/smp_affinity 和 /proc/irq/N/priority 进行调整。

当硬件中断真正发生时，硬件中断向量表会指向一个极简的汇编或C语言 stub。这个 stub 的唯一任务是：

确认中断源。
向中断控制器发送 EOI（End Of Interrupt）。
唤醒对应的 irq/N 内核线程。

之后，中断线程会像其他实时任务一样，根据其优先级和调度策略被调度执行 my_interrupt_handler。这意味着，即使 my_interrupt_handler 内部执行时间较长，它也可以被更高优先级的实时应用线程抢占，从而大大降低了实时任务的延迟。

2. 自旋锁的蜕变：从忙等待到阻塞与优先级继承

自旋锁（spinlock）是通用 Linux 内核中用于保护共享数据结构的关键同步原语。当一个 CPU 核心尝试获取一个已被另一个核心持有的自旋锁时，它会进入一个忙等待循环，反复检查锁的状态，直到锁被释放。在多处理器（SMP）系统中，自旋锁通常不会禁用抢占，但在单处理器（UP）系统中，自旋锁会禁用抢占。

传统自旋锁的问题：优先级反转

在高优先级的实时任务与低优先级的非实时任务共享自旋锁时，优先级反转问题尤为突出：

低优先级任务 L 获取了自旋锁 S。
高优先级实时任务 H 变为可运行状态，并抢占了任务 L。
任务 H 尝试获取自旋锁 S。由于 S 被 L 持有，任务 H 进入忙等待。
由于任务 H 是高优先级，它会持续忙等待，消耗 CPU 资源，但无法获取锁。
任务 L 无法继续执行并释放锁，因为 H 占用了 CPU。
系统陷入僵局，任务 H 被无限期阻塞，或直到某个调度时间片用完，L 才能重新运行并释放锁。这个阻塞时间是不可预测的，无法满足硬实时要求。

PREEMPT_RT 中的自旋锁：rt_mutex 及其优先级继承机制

PREEMPT_RT 的解决方案是，将内核中所有的自旋锁（spinlock_t）在编译时替换为一种特殊的互斥量（rt_mutex），或者至少赋予它们互斥量的行为。rt_mutex 的核心特性是：

阻塞而非忙等待：当一个任务尝试获取一个已被持有的 rt_mutex 时，它不再忙等待，而是进入睡眠状态，将其自身从运行队列中移除，直到锁被释放。这使得 CPU 资源可以被其他可运行的任务使用。
优先级继承 (Priority Inheritance, PI)：这是解决优先级反转问题的关键机制。当一个高优先级任务 H 尝试获取一个被低优先级任务 L 持有的 rt_mutex 时，rt_mutex 会临时将任务 L 的优先级提升到任务 H 的优先级。这样，任务 L 就能以更高的优先级执行，尽快释放锁，从而解除任务 H 的阻塞。一旦任务 L 释放了锁，它的优先级就会恢复到原始值。

机制详解：

PREEMPT_RT 通过宏定义和类型重定义，将内核中的 spinlock_t 类型映射到 raw_spinlock_t 和 rt_mutex。raw_spinlock_t 是真正的自旋锁，只在极少数中断上下文（如中断线程的唤醒路径）中使用，确保极短的临界区。而大多数 spinlock_t 的用法，都被替换为了 rt_mutex 的行为。

改造前后对比表格：

特性	通用 Linux 自旋锁	PREEMPT_RT `rt_mutex` (取代自旋锁)
获取锁失败	忙等待（自旋）	阻塞（任务睡眠，等待锁释放）
优先级反转	容易发生，导致高优先级任务被低优先级阻塞	通过优先级继承机制避免
CPU 利用率	忙等待时浪费 CPU 周期	阻塞时释放 CPU 给其他任务
临界区	短，但不可抢占，可能禁用中断（UP）	短，但可抢占，任务可睡眠

代码示例：rt_mutex 工作原理（简化概念）

在 PREEMPT_RT 内核中，你仍然会看到 spinlock_t 的声明和 spin_lock()/spin_unlock() 的调用。但这些在编译时已经被 PREEMPT_RT 补丁内部重定向到 rt_mutex 相关的函数。

// 假设这是一个内核模块或内核代码片段
#include <linux/spinlock.h> // 实际上在 PREEMPT_RT 中会被重新定义

spinlock_t my_lock; // 在 PREEMPT_RT 中，这实际上是一个 rt_mutex 结构

void __init my_module_init(void) {
    spin_lock_init(&my_lock); // 初始化 rt_mutex
}

void low_priority_task_func(void) {
    // ...
    spin_lock(&my_lock); // 获取 rt_mutex。如果被占用，任务会阻塞并等待。
                         // 如果高优先级任务也等待这个锁，本任务的优先级会被临时提升。
    // 临界区代码
    // ...
    spin_unlock(&my_lock); // 释放 rt_mutex。如果优先级被提升，会恢复到原始优先级。
    // ...
}

void high_priority_task_func(void) {
    // ...
    spin_lock(&my_lock); // 尝试获取 rt_mutex。
                         // 如果被低优先级任务持有，该低优先级任务的优先级会被提升。
                         // 本任务会阻塞，直到低优先级任务释放锁。
    // 临界区代码
    // ...
    spin_unlock(&my_lock);
    // ...
}

通过这种机制，PREEMPT_RT 从根本上消除了自旋锁导致的优先级反转问题，确保了高优先级实时任务的确定性响应。

3. 全抢占内核：无微不至的响应能力

通用 Linux 内核提供了不同级别的抢占模型，通过 CONFIG_PREEMPT 选项进行配置：

CONFIG_PREEMPT_NONE (No Forced Preemption)：只有在任务显式放弃 CPU 或进入睡眠状态时，调度器才能切换任务。
CONFIG_PREEMPT_VOLUNTARY (Voluntary Kernel Preemption)：在内核中插入了一些“抢占点”，允许调度器在这些点进行任务切换。
CONFIG_PREEMPT (Preemptible Kernel, "Desktop" kernel)：允许用户空间进程在内核态执行时被抢占。但内核关键路径（如中断处理、持有自旋锁的临界区）仍然不可抢占。

PREEMPT_RT 引入了最高级别的抢占模型：CONFIG_PREEMPT_RT_FULL (Full Real-Time Preemption)。在这个模式下，内核几乎所有代码都可以被抢占。其实现主要依赖于前面提到的中断线程化和自旋锁到 rt_mutex 的转换。

机制详解：

中断线程化：将中断处理从不可抢占的中断上下文转移到可抢占的内核线程中，使得中断处理本身不再是阻碍抢占的因素。
rt_mutex 替代自旋锁：消除了自旋锁引入的不可抢占临界区和优先级反转，因为任务在等待锁时会阻塞，从而允许其他任务运行。
preempt_disable()/preempt_enable() 的智能处理：在 PREEMPT_RT 中，preempt_disable() 和 preempt_enable() 调用仍然存在，但它们的影响被大大减小。由于 rt_mutex 已经处理了大多数的同步需求，显式禁用抢占的场景变得非常有限，通常只用于一些非常短的、对时间敏感的代码段，且这些代码段必须是无阻塞的。
内核任务的实时调度：许多原本作为内核“内务”的后台任务（如 ksoftirqd, kworker 等）也被转换为可调度线程，并可以配置其优先级。

这意味着，无论内核在执行何种操作，只要有一个更高优先级的实时任务变为可运行状态，它就能够迅速抢占当前正在执行的内核代码，从而获得 CPU 资源。这种无微不至的抢占能力是实现硬实时确定性响应的基石。

4. 高精度定时器：时间精度的飞跃

通用 Linux 内核的定时器通常基于系统时钟节拍（jiffies），其精度受限于 HZ 的值（通常是 100、250 或 1000 Hz）。这意味着定时器事件的粒度通常在毫秒级别，对于需要微秒甚至纳秒级精度的硬实时应用来说是远远不够的。

PREEMPT_RT 启用了 高精度定时器 (High-Resolution Timers, HRT)，由 CONFIG_HIGH_RES_TIMERS 选项控制。HRT 能够利用硬件提供的更高精度的定时器（如 HPET, APIC 定时器等），实现纳秒级的定时器精度。

HRT 工作原理及其对实时性的贡献：

硬件支持：HRT 依赖于能够提供高精度时钟源和中断能力的硬件。
动态调整定时器中断频率：与固定频率的系统时钟节拍不同，HRT 可以根据最近的定时器事件动态调整下一次定时器中断的发生时间。例如，如果下一个事件在 100 微秒后，HRT 就会编程硬件定时器在 100 微秒后产生中断。
精确唤醒：当一个实时任务需要在一个精确的时间点被唤醒时，HRT 能够确保任务在尽可能接近那个时间点被调度。这对于周期性任务（例如控制回路）和事件驱动任务（例如数据采集）至关重要。

API 介绍：

在内核中，HRT 通过 hrtimer 接口提供。用户空间程序则可以通过 POSIX clock_nanosleep()、timer_create() 等 API 来利用高精度定时器。

改造前后对比表格：

特性	通用 Linux 定时器 (jiffies)	PREEMPT_RT 高精度定时器 (HRT)
精度	毫秒级 (受 `HZ` 限制)	纳秒级 (受硬件时钟源限制)
时钟中断	固定频率 (每 `1/HZ` 秒)	动态调整，按需产生中断
任务唤醒	在下一个时钟节拍点或之后	尽可能接近请求的时间点
确定性	较低	较高

高精度定时器是 PREEMPT_RT 确保时间确定性的另一个关键支柱，它使得实时任务能够以极高的精度进行时间同步和事件调度。

5. 用户空间优先级继承：贯穿始终的确定性

优先级继承（Priority Inheritance）不仅仅是内核内部 rt_mutex 的专利。在用户空间，当实时任务通过互斥量（mutex）进行同步时，同样会面临优先级反转问题。

PREEMPT_RT 扩展了优先级继承机制到用户空间，特别是通过 PI-futexes (Priority-Inheritance Futexes)。Futex (Fast Userspace muTEX) 是一种高效的同步原语，它允许用户空间线程在没有内核干预的情况下进行同步，只有在竞争发生时才陷入内核。

PI-futex 的作用：

当一个高优先级的实时线程尝试获取一个被低优先级线程持有的用户空间互斥量（例如 pthread_mutex_t），并且这个互斥量是 PI 类型的，那么内核会：

将高优先级线程阻塞。
临时提升持有互斥量的低优先级线程的优先级，使其与阻塞的高优先级线程的优先级相同。
低优先级线程会以提升后的优先级运行，尽快释放互斥量。
一旦互斥量被释放，高优先级线程被唤醒，低优先级线程的优先级恢复。

通过这种方式，PREEMPT_RT 确保了从内核到用户空间的整个实时执行链条中，优先级反转问题都被有效遏制，为构建端到端确定性实时系统提供了坚实的基础。

PREEMPT_RT带来的影响与优势

通过上述一系列深入的改造，PREEMPT_RT 为 Linux 带来了革命性的实时性能提升：

显著降低延迟：中断延迟和调度延迟显著降低，通常可以达到微秒甚至亚微秒级别。
提高确定性：最坏情况执行时间（WCET）变得可预测和可控，系统响应更加稳定。
消除优先级反转：通过 rt_mutex 和 PI-futex，彻底解决了因锁竞争导致的优先级反转问题。
支持硬实时应用：使得 Linux 能够承担以前只能由专用 RTOS 完成的硬实时任务，例如工业自动化、机器人控制、航空电子、高性能数据采集和医疗设备。
保留 Linux 优势：在提供实时性能的同时，保留了通用 Linux 的所有优势，包括庞大的软件生态系统、丰富的驱动支持、网络功能和开发工具。这意味着开发者可以在一个熟悉的、功能强大的环境中开发实时应用，而无需学习全新的 RTOS。

PREEMPT_RT系统的配置与实践

要将通用 Linux 改造为 PREEMPT_RT 系统，通常需要以下步骤：

1. 补丁应用与内核编译

PREEMPT_RT 通常以补丁的形式提供，需要手动将其应用到 Linux 内核源代码树上，然后重新编译内核。

获取内核源代码：从 kernel.org 下载与你的 PREEMPT_RT 补丁版本兼容的 Linux 内核源代码。
获取 PREEMPT_RT 补丁：从 https://www.kernel.org/pub/linux/kernel/projects/rt/ 获取对应版本的补丁。

应用补丁：

cd /usr/src/linux-<version>
patch -p1 < /path/to/your/rt-patch-<version>.patch

配置内核：
```
make menuconfig
```
在配置界面中，导航到 Processor type and features -> Preemption Model，选择 Fully Preemptible Kernel (RT)。
同时，确认 High Resolution Timers (CONFIG_HIGH_RES_TIMERS) 已启用。
你可能还需要调整其他与实时性相关的选项，例如：
- Timer frequency (通常设置为 1000Hz)。
- NO_HZ_FULL (Full dynticks system) 可以减少空闲 CPU 的定时器中断。
- NUMA 选项的调整（如果你的系统支持 NUMA）。
编译和安装内核：
```
make -j$(nproc) bzImage modules
sudo make modules_install
sudo make install
```
更新 GRUB 配置并重启系统，选择新编译的实时内核。

2. 调度策略：SCHED_FIFO与SCHED_RR

Linux 提供了 POSIX 实时调度策略：

SCHED_FIFO (First-In, First-Out)：一旦一个 SCHED_FIFO 任务获得 CPU，它会一直运行直到它自愿放弃 CPU（例如，等待一个事件），或者被更高优先级的 SCHED_FIFO 或 SCHED_RR 任务抢占。相同优先级的 SCHED_FIFO 任务之间不会发生抢占，先运行的会一直运行。
SCHED_RR (Round-Robin)：与 SCHED_FIFO 类似，但它引入了时间片（timeslice）。当一个 SCHED_RR 任务的时间片用尽后，如果还有相同优先级的其他 SCHED_RR 任务处于可运行状态，调度器会将其抢占并调度下一个相同优先级的 SCHED_RR 任务。

实时任务的优先级范围通常是 1 到 99（0 留给普通调度策略）。数字越大，优先级越高。

设置调度策略和优先级：

命令行工具：chrt 命令可以用于设置进程的调度策略和优先级。

chrt -f 99 ./my_realtime_app  # 设置为 SCHED_FIFO，优先级 99
chrt -r 50 ./my_realtime_app  # 设置为 SCHED_RR，优先级 50

C/C++ API：在程序内部，可以使用 sched_setscheduler() 和 pthread_setschedparam() 等函数。

3. 内存锁定与CPU亲和性

内存锁定 (mlockall())：为了避免实时任务在执行过程中发生页面置换导致的延迟，实时应用程序应该将其使用的所有内存锁定在物理内存中。这可以通过 mlockall(MCL_CURRENT | MCL_FUTURE) 系统调用实现。
```
#include <sys/mman.h>
// ...
if (mlockall(MCL_CURRENT | MCL_FUTURE) == -1) {
    perror("mlockall failed");
    exit(EXIT_FAILURE);
}
// ...
```
CPU 亲和性 (taskset, sched_setaffinity())：为了减少缓存抖动和跨 CPU 迁移的开销，可以将实时任务绑定到特定的 CPU 核心上。这可以通过 taskset 命令或 sched_setaffinity() API 实现。
```
taskset -c 0 chrt -f 99 ./my_realtime_app # 将实时应用绑定到 CPU 0
```
对于中断线程，可以通过 /proc/irq/N/smp_affinity 来设置其 CPU 亲和性。

4. 实时性验证工具

cyclictest：这是 rt-tests 包中的一个标准工具，用于测量系统最坏情况的调度延迟。它会创建多个高优先级的实时线程，周期性地唤醒它们，并测量从唤醒到实际运行的时间差。
```
cyclictest -l100000 -m -n -q -D10s -i1000 -p99 # 运行 10 万次，测量最低优先级为 99 的任务的延迟
```
oslat (Operating System Latency Test)：另一个 rt-tests 包中的工具，用于测量各种操作（如上下文切换、互斥锁获取）的延迟。
hwlatdetect：用于检测硬件层面的不可避免的延迟。

实时应用程序的开发范式

在 PREEMPT_RT Linux 上开发硬实时应用程序，需要遵循一些特定的编程范式和最佳实践：

1. POSIX 实时扩展

充分利用 POSIX 实时扩展（PSE51），包括：

线程管理：pthread_attr_setschedpolicy() 和 pthread_setschedparam() 用于设置线程的实时调度策略和优先级。
同步原语：使用 pthread_mutex_t 配合 PTHREAD_PRIO_INHERIT 属性来启用优先级继承，或者使用信号量 (sem_t)。
定时器：timer_create(), timer_settime(), clock_nanosleep() 等高精度定时器 API。
消息队列：mq_open(), mq_send(), mq_receive() 等用于实时任务间通信。

2. 内存管理与同步机制的选择

避免动态内存分配：在实时任务的关键路径中，尽量避免使用 malloc() 或 new 进行动态内存分配，因为它们可能导致不可预测的延迟（如堆碎片整理、系统调用开销）。提前分配好所有所需内存。
使用无锁数据结构：在某些极端对延迟敏感的场景，可以考虑使用无锁（lock-free）或无等待（wait-free）数据结构，以避免任何形式的锁竞争。但这需要深入的专业知识。
限制 I/O 操作：文件 I/O、网络 I/O 等操作通常具有较高的不确定性。尽量将这些操作放在非实时线程中执行，或者使用异步 I/O。
使用内存映射 I/O (MMIO)：对于与硬件设备的直接交互，MMIO 通常比传统的设备驱动程序接口提供更低的延迟。

3. 代码示例：一个简单的实时线程

这是一个使用 SCHED_FIFO 调度策略和 mlockall() 的简单实时线程示例。

#include <iostream>
#include <pthread.h>
#include <sched.h>
#include <unistd.h>
#include <sys/mman.h>
#include <time.h>
#include <errno.h>
#include <string.h> // For strerror

#define THREAD_PRIORITY 90
#define THREAD_STACK_SIZE (1024 * 1024) // 1MB stack
#define PERIOD_NS 100000000 // 100ms in nanoseconds

// 实时线程函数
void* realtime_thread_func(void* arg) {
    std::cout << "Real-time thread started with priority: " << THREAD_PRIORITY << std::endl;

    struct timespec next_period;
    clock_gettime(CLOCK_MONOTONIC, &next_period); // 获取当前时间作为起始点

    while (true) {
        // 模拟实时任务的工作
        // 这里应放置实际的控制逻辑、传感器数据读取、执行器命令发送等
        // 确保这段代码的执行时间是可预测且低于 PERIOD_NS
        std::cout << "Real-time task executed at " << next_period.tv_sec << "." << next_period.tv_nsec << std::endl;

        // 计算下一个周期的时间
        next_period.tv_nsec += PERIOD_NS;
        while (next_period.tv_nsec >= 1000000000) {
            next_period.tv_nsec -= 1000000000;
            next_period.tv_sec++;
        }

        // 睡眠直到下一个周期
        int ret = clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &next_period, NULL);
        if (ret != 0) {
            if (ret == EINTR) {
                // 被信号中断，重新计算 next_period 并重试睡眠
                // 在实际应用中，需要更复杂的信号处理
                std::cerr << "Warning: clock_nanosleep interrupted." << std::endl;
                // 为了简化，这里直接退出，实际应用应重新计算 next_period
                // 或使用 sigwaitinfo 等更安全的信号处理方式
                break;
            } else {
                std::cerr << "Error in clock_nanosleep: " << strerror(ret) << std::endl;
                break;
            }
        }
    }

    std::cout << "Real-time thread exited." << std::endl;
    return NULL;
}

int main() {
    // 1. 锁定所有内存，避免页面置换
    if (mlockall(MCL_CURRENT | MCL_FUTURE) == -1) {
        perror("mlockall failed");
        std::cerr << "Make sure you run this with root privileges, or set CAP_IPC_LOCK capability." << std::endl;
        return EXIT_FAILURE;
    }
    std::cout << "Memory locked successfully." << std::endl;

    // 2. 设置主进程的调度策略和优先级（可选，但通常推荐）
    // 确保主进程不会干扰实时线程
    struct sched_param main_params;
    main_params.sched_priority = 0; // 普通优先级
    if (sched_setscheduler(0, SCHED_OTHER, &main_params) == -1) {
        perror("sched_setscheduler for main process failed");
        // 不影响实时线程的创建，所以不是致命错误
    }

    // 3. 设置实时线程的属性
    pthread_attr_t thread_attr;
    pthread_attr_init(&thread_attr);
    pthread_attr_setstacksize(&thread_attr, THREAD_STACK_SIZE); // 设置栈大小

    struct sched_param param;
    param.sched_priority = THREAD_PRIORITY;
    pthread_attr_setschedpolicy(&thread_attr, SCHED_FIFO);
    pthread_attr_setschedparam(&thread_attr, &param);

    // 确保创建的线程是可分离的，避免僵尸线程
    pthread_attr_setdetachstate(&thread_attr, PTHREAD_CREATE_JOINABLE);

    // 4. 创建实时线程
    pthread_t realtime_tid;
    if (pthread_create(&realtime_tid, &thread_attr, realtime_thread_func, NULL) != 0) {
        perror("pthread_create failed");
        pthread_attr_destroy(&thread_attr);
        return EXIT_FAILURE;
    }

    pthread_attr_destroy(&thread_attr);

    // 5. 主线程等待实时线程完成（在此示例中，实时线程会无限循环，所以主线程可以做其他事情或等待）
    std::cout << "Main thread running. Press Ctrl+C to terminate." << std::endl;

    // 在实际应用中，主线程可能负责非实时任务，如用户界面、日志记录等
    // 这里简单地等待一段时间，或等待信号
    sleep(10); // 运行 10 秒后主线程退出，实时线程也会被终止

    // 如果实时线程有退出条件，可以使用 pthread_join
    // pthread_join(realtime_tid, NULL);

    std::cout << "Main thread exiting." << std::endl;

    // 6. 解锁内存 (可选，通常在程序退出时自动解锁)
    // munlockall(); 

    return EXIT_SUCCESS;
}

编译和运行：

g++ -o realtime_app realtime_example.cpp -lrt -pthread
sudo ./realtime_app

注意：运行此程序需要 root 权限或为可执行文件设置 CAP_IPC_LOCK 和 CAP_SYS_NICE 能力，以便 mlockall 和设置实时调度策略能够成功。

sudo setcap 'cap_ipc_lock,cap_sys_nice=+ep' ./realtime_app
./realtime_app

PREEMPT_RT的局限与权衡

尽管 PREEMPT_RT 极大地提升了 Linux 的实时性能，但它并非没有代价和局限性：

性能开销：中断线程化和 rt_mutex 引入了额外的上下文切换和锁管理开销。虽然这些开销在实时性方面是值得的，但在纯粹的吞吐量测试中，PREEMPT_RT 内核可能会比通用内核表现稍差。
调试复杂性：PREEMPT_RT 对内核的深入修改增加了调试的复杂性，尤其是在出现难以追踪的延迟问题时。
驱动兼容性：一些设计不佳的设备驱动程序，特别是那些严重依赖传统自旋锁行为或禁用中断的驱动，可能在 PREEMPT_RT 内核上出现问题或需要修改。
并非万能药：PREEMPT_RT 提供了实时操作系统的基础，但高质量的实时应用程序仍然需要仔细设计，避免长临界区、不确定的 I/O 和内存分配等问题。它不能神奇地将糟糕的代码变成实时代码。
硬件依赖：高精度定时器等功能依赖于底层硬件的支持。
维护成本：PREEMPT_RT 补丁需要与最新的 Linux 内核版本保持同步，这需要持续的社区努力。

展望未来

PREEMPT_RT 补丁的最终目标是将其所有核心功能逐步合并到主流 Linux 内核中。事实上，自 Linux 5.x 版本以来，越来越多的 PREEMPT_RT 特性已经被上游内核接受和集成。例如，中断线程化的大部分工作和 hrtimer 已经在主流内核中。完全的 PREEMPT_RT 功能可能最终会成为一个可选的编译配置，而不是一个外部补丁。这将极大地简化实时 Linux 的部署和维护。

PREEMPT_RT 补丁是 Linux 社区在实时领域的一项里程碑式成就。它使得 Linux 能够承担最严苛的实时应用，同时保留了其作为通用操作系统的强大功能和灵活性。理解其背后的原理和实践，对于任何希望在 Linux 平台上构建高性能、高确定性系统的工程师来说，都至关重要。

结语

通过将中断线程化、自旋锁转换为优先级继承互斥量，并实现全抢占内核与高精度定时器，PREEMPT_RT 彻底改变了 Linux 的实时能力。它为开发者提供了一个强大的平台，用于构建复杂且对时间敏感的硬实时系统，同时充分利用了 Linux 丰富的生态系统。

开场：硬实时系统的挑战与Linux的不足

PREEMPT_RT的核心理念：一切皆可抢占

深度解析PREEMPT_RT的关键改造

1. 中断线程化：IRQ处理的革命

2. 自旋锁的蜕变：从忙等待到阻塞与优先级继承

3. 全抢占内核：无微不至的响应能力

4. 高精度定时器：时间精度的飞跃

5. 用户空间优先级继承：贯穿始终的确定性

PREEMPT_RT带来的影响与优势

PREEMPT_RT系统的配置与实践

1. 补丁应用与内核编译

2. 调度策略：SCHED_FIFO与SCHED_RR

3. 内存锁定与CPU亲和性

4. 实时性验证工具

实时应用程序的开发范式

1. POSIX 实时扩展

2. 内存管理与同步机制的选择

3. 代码示例：一个简单的实时线程

PREEMPT_RT的局限与权衡

展望未来

结语

发表回复 取消回复

发表回复取消回复