Linux

前言 在实时系统的世界里，调度算法是灵魂。一个优秀的调度算法可以在同样的硬件上，让更多任务按时完成；而一个糟糕的调度算法，即使是性能过剩的CPU，也可能出现任务超时。 我第一次深刻体会到调度的重要性是在 2019 年的一个工业控制项目。当时我们用的是某款主流 RTOS，系统中有 12 个周期性任务，利用率大约在 75%。按照传统的经验法则，这是一个相当安全的数值。然而，在一次现场测试中，当某个外部设备突然产生大量数据时，系统中优先级最低的那个数据记录任务竟然连续三次错过了截止期——每一次超时都意味着一条生产数据的丢失。 问题排查了整整三天，最后我们发现：系统中高优先级的任务虽然单个执行时间不长，但它们加起来的"时间碎片"效应，导致低优先级任务连续被抢占了 150 毫秒。而这个任务的截止期只有 100 毫秒。更讽刺的是，如果我们把所有任务的优先级都设成一样，采用时间片轮转，反而不会出现这个问题。 那一天我意识到：实时调度不是简单的"优先级高先执行"这么简单。 它是一门严谨的科学，有完善的理论基础和严格的可调度性证明。 这篇文章就是我对实时调度算法的系统性总结。从最经典的速率单调（RM）算法，到最优的最早截止期优先（EDF）算法，再到 Linux 内核中 SCHED_DEADLINE 的实际实现，我会带你一步步理解实时调度的核心原理，并提供可运行的代码示例。 一、实时调度的基本概念 在深入具体算法之前，我们需要先建立一些基本概念。这些概念是理解所有实时调度算法的基础。 1.1 什么是实时系统？ 实时系统的定义很简单： 实时系统是指系统的正确性不仅取决于计算的逻辑结果，还取决于结果产生的时间。 换句话说，在实时系统中，“晚到的正确答案就是错误答案”。 实时系统通常分为两类： 硬实时系统（Hard Real-Time）：绝对不允许任何任务错过截止期，一次错过就是系统失败。例如汽车的安全气囊控制系统、飞机的飞行控制系统。 软实时系统（Soft Real-Time）：允许偶尔错过截止期，错过的后果是性能下降而非系统失败。例如视频播放器、音频处理系统。 本文讨论的调度算法主要针对硬实时系统，但其中的原理同样适用于软实时系统。 1.2 实时任务模型 在调度理论中，我们通常用一个简化的模型来描述实时任务。对于周期性任务，最经典的模型包含三个参数： τi = (Ci, Ti, Di) 其中： Ci（Computation Time）：任务最坏情况下的执行时间 Ti（Period）：任务的周期，即两次释放之间的时间间隔 Di（Relative Deadline）：任务的相对截止期，即从任务释放到必须完成的时间 在很多情况下，我们假设 Di = Ti，也就是截止期等于周期。这是一个常见但非必须的假设。 举个具体的例子： τ1 = (1, 3, 3) # 每3毫秒执行一次，需要1毫秒，3毫秒内必须完成 τ2 = (2, 5, 5) # 每5毫秒执行一次，需要2毫秒，5毫秒内必须完成 τ3 = (3, 8, 8) # 每8毫秒执行一次，需要3毫秒，8毫秒内必须完成 1....

前言 在工业控制、机器人、汽车电子等领域，确定性比平均性能更加重要。一个控制系统如果不能在规定的时间窗口内完成响应，即使平均响应时间再短，也可能导致灾难性的后果——生产线停摆、机器人失控、汽车 ADAS 失效。 传统的 Linux 内核虽然在吞吐量和平均延迟方面表现出色，但在最坏情况延迟（Worst-Case Latency）方面却不尽人意。在高负载情况下，普通 Linux 内核的调度延迟可能达到数十毫秒甚至数百毫秒级别，这对于要求微秒级确定性的实时应用来说是完全不可接受的。 这就是 PREEMPT_RT 补丁存在的意义。 PREEMPT_RT（Real-Time Preemption Patch）是一组针对 Linux 内核的补丁集，其目标是将 Linux 内核改造为一个完全可抢占的实时操作系统。经过二十多年的发展，PREEMPT_RT 已经从一个实验性项目成长为工业级实时解决方案的事实标准，大量关键代码甚至已经合入主线内核。 本文将从实时系统的基本概念出发，深入解析 PREEMPT_RT 的核心原理，带你从零开始打补丁、编译实时内核、配置系统、进行延迟测试，最终构建一个真正满足工业级要求的实时 Linux 系统。 一、什么是真正的实时系统？ 在深入 PREEMPT_RT 之前，我们首先需要澄清一个普遍的误解：快 ≠ 实时。 很多开发者一听到"实时系统"，第一反应就是"运行很快的系统"。这是一个根本性的错误认知。 1.1 实时性的本质：确定性 实时系统的核心特征不是"快"，而是可预测性或确定性。系统必须能够保证：关键任务在截止时间之前完成。 让我们通过一个具体的例子来说明： 假设我们有一个工业机器人的运动控制系统，要求每 1 毫秒执行一次位置控制循环。如果控制系统的响应时间分布如下： 系统 A：平均响应 500 微秒，最坏情况 1.5 毫秒（偶尔超时） 系统 B：平均响应 800 微秒，最坏情况 950 微秒（从不超时） 哪个系统是"实时"的？ 答案是 系统 B。尽管它的平均响应更慢，但它的最坏情况延迟始终小于截止时间，具有完美的确定性。而系统 A 虽然更快，但偶尔会超时，在实际工业场景中这可能导致机器人运动轨迹偏差、甚至发生碰撞。 1.2 实时系统的分类 根据对截止时间的要求严格程度，实时系统可以分为三类： 硬实时（Hard Real-Time） 绝对不能错过截止时间 错过 = 系统失败 典型场景：航空电子、汽车安全系统、工业控制 PREEMPT_RT 目标：在合理配置下达到硬实时级别 软实时（Soft Real-Time）...

引言 本文基于 2026 年最新行业资料整理，涵盖 embedded Linux development 的核心概念、开发流程和实战技巧。 嵌入式 Linux 架构 ┌─────────────────┐ │ 应用层 │ ├─────────────────┤ │ 库层 │ glibc/μClibc ├─────────────────┤ │ 系统调用 │ ├─────────────────┤ │ Linux 内核 │ ├─────────────────┤ │ BSP/驱动 │ └─────────────────┘ 开发环境搭建 # 安装交叉编译工具链 sudo apt install gcc-arm-linux-gnueabihf # 编译内核 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage # 编译设备树 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- dtbs 驱动开发 // 字符设备驱动框架 static int dev_open(struct inode *inode, struct file *file) { printk(KERN_INFO "设备已打开 "); return 0; } static ssize_t dev_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) { copy_to_user(buf, kernel_data, count); return count; } static struct file_operations fops = { ....