介绍

优先级反转是实时和并发系统中的经典调度问题。

当高优先级任务被迫等待低优先级任务完成时，就会发生这种情况，而中等优先级任务可以继续执行。

基本模型包含三个任务：

重要的区别在于：

优先级反转是问题所在。优先级继承是缓解这一问题的机制之一。

本文从 Linux 内核的角度，利用内核线程和 Linuxrt_mutex机制来探讨这一概念。

什么是优先级反转？

假设一个低优先级任务获得了一个互斥锁。

随后，一项高优先级任务需要使用同一个互斥锁。

由于资源当前由 LOW 所有，因此高优先级任务无法继续执行。

当 MEDIUM 获得 CPU 时间而 LOW 无法完成其关键部分时，情况就会变得棘手。

逻辑顺序是：

• LOW 获取互斥锁。

• HIGH 尝试获取互斥锁。

• 高块。

• MEDIUM 执行无关工作。

• LOW 延迟。

• HIGH 仍然被阻塞。

• LOW 最终释放了互斥锁。

• HIGH 终于可以继续了。

令人惊讶的是，HIGH 的优先级高于 MEDIUM 和 LOW，但 MEDIUM 却可能间接导致 HIGH 的延迟。

这就是优先级倒置的本质。

优先级反转与优先级继承

这两个术语不应混淆。

重要的关系是：

Priority inversion = problem
Priority inheritance = mitigation

经典示例

考虑：

HIGH    = 80
MEDIUM  = 50
LOW     = 10

LOW 首先获取共享资源。

HIGH 稍后需要相同的资源。

因此，高位会阻塞。

如果 MEDIUM 可以在 LOW 等待 CPU 时间时执行，则 HIGH 的有效等待时间可能会增加。

从概念上讲：

LOW owns resource
        ↓
HIGH needs resource
        ↓
HIGH blocks
        ↓
MEDIUM executes
        ↓
LOW is delayed
        ↓
HIGH remains blocked

这就是为什么在响应时间可预测性很重要的系统中，优先级反转至关重要的原因。

什么是优先继承？

优先级继承解决了等待任务与锁所有者之间的依赖关系。

如果 HIGH 正在等待 LOW 拥有的互斥锁，则 LOW 可以暂时继承 HIGH 的优先级。

从概念上讲：

LOW priority: 10
        ↓
HIGH waits
        ↓
LOW temporarily inherits HIGH's priority
        ↓
LOW completes critical section
        ↓
LOW releases mutex
        ↓
HIGH continues
        ↓
LOW returns to its original priority

目标很明确：

允许优先级较低的锁持有者更快地完成关键部分，以便优先级较高的等待者可以继续执行。

现实世界中的致命故障（Autopilot & Finance）

理解优先级继承不能仅停留在教科书层面。在现实世界中，“优先级反转”是导致自动驾驶规控模块超时和金融高频交易系统滑点（Slippage）的隐形杀手。例如，在Autosar或ROS 2机器人系统中，摄像头数据流（高优先级）偶尔会因底层日志服务（低优先级）持有共享内存锁而出现数毫秒的卡顿，若此时CPU被网络管理进程（中等优先级）抢占，轻则丢帧，重则触发看门狗（Watchdog）强行重启整个域控制器。正是这种“确定性缺失”，驱使Linux内核社区持续强化rt_mutex，并在PREEMPT_RT补丁集中将其彻底优化为可抢占的等待机制。

为什么rt_mutex这在 Linux 中很重要

Linux 内核提供rt_mutex了一个具有优先级继承支持的实时互斥锁实现。

一个简化的例子是：

static struct rt_mutex lock;

rt_mutex_init(&lock);

rt_mutex_lock(&lock);

/* critical section */

rt_mutex_unlock(&lock);

重要的 API 调用包括：

• rt_mutex_init()

• rt_mutex_lock()

• rt_mutex_unlock()

在演示模块中，共享锁声明如下：

static struct rt_mutex pi_lock;

并在模块加载期间初始化。

内核线程

该演示使用了 Linux 内核线程，而不是普通的用户空间进程。

这三个概念参与者是：

• 低的

• 高的

• 中等的

可以使用以下 API 创建内核线程：

kthread_run(low_thread, NULL, "pi_low");

返回的task_struct指针允许模块保留对已创建的内核线程的引用。

例如：

static struct task_struct *low_task;

高和中难度也采用相同的方法。

低线

LOW负责收购rt_mutex。

关键操作是：

rt_mutex_lock(&pi_lock);

获取锁之后，LOW 进入其关键部分。

该演示故意让 LOW 持有互斥锁一段时间，以便 HIGH 可以尝试获取它。

因此，重要的关系是：

LOW拥有资源，而HIGH需要资源。

该模块还会在交互之前和交互期间打印调度信息。

高线

HIGH 尝试获取同一个互斥锁：

rt_mutex_lock(&pi_lock);

如果 LOW 已经持有互斥锁，则 HIGH 阻塞。

概念状态是：

HIGH
  ↓
waiting for mutex
  ↓
LOW owns mutex

这是优先级继承变得重要的关键点。

LOW 释放互斥锁后，HIGH 可以获取它并继续执行。

中等长度的线

MEDIUM 代表独立作品。

它不需要共享互斥锁。

它的目的是模拟优先级反转场景中的经典第三方参与者。

简化后的模型如下：

因此，MEDIUM 很重要，因为它说明了与共享资源没有直接关系的任务仍然会影响 HIGH 的等待时间。

Linux 5.15 的限制

这个实验中有一个重要的实施细节。

目标环境为Ubuntu Linux 5.15.x。

早期版本曾尝试使用：

sched_setscheduler_nocheck()

分配任意调度器优先级。

但是，该调度器接口并未导出供目标 Ubuntu 内核中的外部可加载模块使用。

因此，该模块不能简单地依赖于该内部调度器接口。

因此，该实现使用了诸如以下导出的辅助函数：

sched_set_fifo_low(low_task);
sched_set_fifo(high_task);

这是Linux内核开发中的一个重要教训：

内核源代码中存在的 API 并不意味着内核外部的模块就可以调用它。

现代观测性：如何用 ftrace 实时追踪 PI 行为

仅仅依赖 dmesg 打印日志来观察优先级继承，犹如“隔皮猜瓜”。在真实的性能诊断场景中，SRE和内核工程师必须依赖 ftrace 和 trace-cmd 来捕获内核调度器的实时事件。当你的服务器出现疑似优先级反转导致的延时毛刺时，强烈建议开启调度事件追踪：

trace-cmd record -e sched:* -e rt:* -T sleep 10
trace-cmd report | grep -E "PI|mutex|prio"

通过追踪 sched_switch 和 sched_wakeup 事件，你可以亲眼见证 LOW 任务的实际 prio 值在 HIGH 阻塞的瞬间，从理论值 10 被短暂“升职”至 80（继承值），并在释放锁后复位。这种动态可视化远比静态的打印语句更具说服力，也是排查生产环境“幽灵超时”问题的金标准。

理论优先级与实际调度器状态

教科书中常用的例子是：

LOW    = 10
MEDIUM = 50
HIGH   = 80

但是，这些数字不应与该模块的实际调度器状态混淆。

当前实现使用了外部模块可用的调度器辅助函数。

因此，该项目特意区分了以下几点：

概念模型

LOW    = 10
MEDIUM = 50
HIGH   = 80

实际执行

LOW    → sched_set_fifo_low()
HIGH   → sched_set_fifo()
MEDIUM  → normal kernel thread

该模块会打印实际的调度字段，例如：

• current->pid

• current->policy

• current->prio

• current->normal_prio

这比假设理论优先级值就是实际运行时值要好。

标准 Ubuntu 内核与 PREEMPT_RT 内核

另一个重要的限制是内核配置。

目标环境是标准/非PREEMPT_RTUbuntu内核。

这意味着该项目主要应被视为Linux 内核 rt_mutex 和优先级继承学习实验，而不是确定性的实时基准测试。

具体的时间安排和调度行为可能取决于：

• 内核配置

• 调度器行为

• CPU拓扑结构

• 系统负载

• 抢占配置

• 时机msleep()

• 排班政策

对于具有受控优先级的严格教科书式实时演示10 / 50 / 80，PREEMPT_RT 内核或适当设计的用户空间 POSIX 实验可能是更好的环境。

为什么msleep()使用

演示中使用了如下延迟：

msleep(1000);

这些延迟并非旨在提供精确的实时调度。

他们的目的是为示威活动创造足够的时间间隔：

• LOW 获得开始时间。

• HIGH 获得开始时间。

• LOW 获取互斥锁。

• HIGH 随后尝试使用互斥锁。

• MEDIUM 开始工作。

因此，msleep()应该将其理解为一种演示计时机制，而不是一种实时同步机制。

模块生命周期

内核模块具有重要的生命周期：

Build
  ↓
Load
  ↓
Initialize
  ↓
Create kernel threads
  ↓
Run demonstration
  ↓
Synchronize completion
  ↓
Stop threads
  ↓
Unload

模块入口点为：

static int __init pi_demo_init(void)

模块出口点为：

static void __exit pi_demo_exit(void)

它们通过以下方式连接：

module_init(pi_demo_init);
module_exit(pi_demo_exit);

为什么模块清理很重要

内核线程生命周期管理尤为重要。

该项目早期版本在运行期间出现内核错误：

sudo rmmod pi_demo

报告的指令指针与以下内容相关联：

kthread_stop()

这凸显了一条重要的内核编程规则：

创建内核线程只是问题的一半，你还必须正确管理它的整个生命周期。

模块必须谨慎处理：

• 创建主题

• 线程执行

• 线程阻塞

• 线程终止

• kthread_stop()

• 模块移除

利用完工进行安全清理

当前设计使用内核补全对象：

static DECLARE_COMPLETION(demo_done);

实际演示结束后，高电平信号表示演示完成：

complete(&demo_done);

模块清理路径会等待该事件发生：

wait_for_completion(&demo_done);

这样，模块在进行清理工作之前就有一个清晰的同步点。

因此，生命周期为：

• 开始演示。

• HIGH 完成。

• 高信号demo_done。

• 模块清理工作正在等待完成。

• 清理操作会终止线程。

• 模块已卸载。

这比不考虑线程当前状态而盲目停止线程要安全得多。

task_struct和调度程序信息

该模块使用以下方式存储线程引用：

struct task_struct *

可以通过以下方式访问当前正在执行的任务：

current

该演示程序会打印当前任务的调度器相关信息。

例如：

pr_info("PID=%d policy=%d prio=%d normal_prio=%d\n",
        current->pid,
        current->policy,
        current->prio,
        current->normal_prio);

这很有用，因为内核实验应该区分以下情况：

• 源代码的意图是什么？

• 调度器接口请求的内容

• 以及内核实际报告的内容。

观察实验dmesg

内核模块通常使用内核日志 API 而不是printf()。

演示中使用了如下信息：

pr_info("PI-DEMO: HIGH trying to acquire rt_mutex\n");

您可以使用以下命令过滤内核日志：

sudo dmesg | grep PI-DEMO

实时输出：

sudo dmesg -w

这样就可以在内核线程执行的同时观察实验结果。

实用命令

建造

make

检查模块

ls -lh pi_demo.ko

加载

sudo insmod ./pi_demo.ko

检查输出

sudo dmesg | grep PI-DEMO

关注实时输出

sudo dmesg -w

消除

sudo rmmod pi_demo

检查是否已加载

lsmod | grep pi_demo

查看最近的消息

sudo dmesg | tail -30

检查完整的PI演示

sudo dmesg | grep -A80 -B20 "PI-DEMO"

搜索内核问题

sudo dmesg | grep -E "BUG:|Oops:|WARNING:|PI-DEMO|kthread_stop" | tail -100

推荐的实验室工作流程

一个规范的实验可以遵循以下步骤：

步骤 1 — 构建

make

步骤 2 — 验证模块

ls -lh pi_demo.ko

步骤 3 — 加载

sudo insmod ./pi_demo.ko

步骤 4 — 观察输出

sudo dmesg | grep PI-DEMO

或者：

sudo dmesg -w

步骤 5 — 完成后将其移除

sudo rmmod pi_demo

步骤 6 — 验证清理情况

sudo dmesg | tail -30

步骤 7 — 验证模块状态

lsmod | grep pi_demo

本项目教会我们什么

这个相对较小的模块涉及几个重要的 Linux 内核概念。

内核模块

• module_init()

• module_exit()

• MODULE_LICENSE()

• MODULE_AUTHOR()

• MODULE_DESCRIPTION()

• MODULE_VERSION()

内核线程

• kthread_run()

• kthread_stop()

• kthread_should_stop()

• struct task_struct

同步

• rt_mutex

• rt_mutex_init()

• rt_mutex_lock()

• rt_mutex_unlock()

完成

• DECLARE_COMPLETION()

• complete()

• wait_for_completion()

日程安排

• sched_set_fifo()

• sched_set_fifo_low()

• current->policy

• current->prio

• current->normal_prio

调试

• pr_info()

• pr_err()

• dmesg

• 内核崩溃

• 内核警告

• 线程清理

常见的概念性错误

错误 1：优先级反转意味着 LOW 始终在 HIGH 之前执行。

不完全是。

问题在于资源依赖性。

HIGH 被阻塞，因为 LOW 拥有 HIGH 需要的资源。

错误 2：优先级继承意味着低优先级永久变为高优先级

不。

这种继承是暂时的，并且与锁依赖项相关。

相关资源释放后，即可移除继承的优先级。

错误三：rt_mutex使整个系统实时运行

不。

使用该方法rt_mutex并不会自动将标准的 Ubuntu 内核转换为确定性的实时操作系统。

内核配置和调度行为仍然很重要。

错误 4：sched_set_fifo()允许外部模块选择任意优先级

不。

导出的辅助函数不提供任意数值优先级分配，例如：

10
50
80

这是开发过程中遇到的重要制约因素之一。

误区五：代码能编译rmmod就一定安全。

不。

模块清理是内核正确性的一部分。

线程生命周期错误只会在模块移除期间出现。

一句话概括优先继承

优先级继承会暂时提高持有高优先级任务所需资源的低优先级任务的有效优先级，从而帮助锁持有者更快地完成并释放资源。

最终结论

优先级反转表明为什么同步和调度不能完全独立地研究。

互斥锁决定谁可以访问某个资源。

调度器决定哪个可运行的任务获得 CPU 时间。

当高优先级任务被低优先级锁持有者阻塞时，优先级继承将这两个问题联系起来。

在 Linux 中，rt_mutex它提供了用于优先级继承的内核机制。

该项目结合了：

最重要的一课不仅仅是如何打电话rt_mutex_lock()。

它指的是理解以下各项之间的完整关系：

任务 → 调度器 → 资源 → 互斥锁 → 阻塞 → 优先级继承 → 临界区 → 解锁 → 任务生命周期 → 模块清理。

云原生与 Cgroup 调度带来的新维度

在当今的 Kubernetes 容器化环境中，Linux 调度器面临比传统物理机更复杂的局面。Cgroup v2 的 CPU 带宽控制（CFS Quota）与优先级继承存在微妙的相互影响。

想象一下：LOW 任务虽然临时继承了 HIGH 的高优先级（如 SCHED_FIFO 80），但如果该任务所在的 Pod 或 Cgroup 被配置了 cpu.max 限制（例如仅允许使用 50ms 的时间片），那么即使调度优先级再高，LOW 任务依然会受到 Cgroup 限流，被迫节流（Throttled）。这导致一个尴尬的局面——HIGH 任务虽然逻辑上解除了锁依赖，却依然因为 LOW 任务的 Cgroup 配额耗尽而延误。

因此，现代服务器调优必须建立“双层调度观”：

• 顶层：Cgroup 的带宽配额决定了任务能获得多少绝对 CPU 时间。

• 底层：rt_mutex 和优先级继承决定了竞争同一资源时，谁拥有插队的绝对优先权。

建议：在部署关键实时应用（如 5G UPF 网元或高频交易容器）时，务必使用 cpuset 将关键业务线程与已绑定 CPU 隔离，并慎重评估是否开启 Cgroup 的 CPU 带宽限制，否则你耗费精力调优的 rt_mutex 可能在生产洪峰流量下收效甚微。同时，卸载此类内核模块时，除了使用文中提到的 completion 同步，建议在生产环境中配套 crash_kexec_post_reboot 等兜底机制，以防极端情况下的模块清理失败导致节点不可用。