实时抢占的真正终局
让 Linux 内核对实时工作负载实现完全可抢占的努力，凸显了在一个大型通用操作系统中保证有界延迟有多难，尤其是在像 `printk` 这样看似简单的日志记录周围。评论者将 Linux 的软实时目标与航电、机器人和工业控制等领域的硬实时需求进行对比，认为真正的安全关键系统仍会倾向于小型 RTOS 或微内核，而主线实时 Linux 则可以显著改善音频、视频以及某些嵌入式控制应用的延迟和抖动。许多人认为，这项工作与其说是要取代专用 RTOS 栈，不如说是“良好的基础卫生”，它让 Linux 在负载下表现得更可预测，同时保留其广泛的硬件和软件生态系统。
实时日志记录与 printk
- 在内核和 RT 上下文中打印很难：同步日志记录可能会在缓慢 I/O 上阻塞，并破坏实时保证。
- 常见模式：带覆盖或丢弃的环形缓冲区、低优先级刷新线程，以及在负载下接受数据丢失。
- 关于丢弃最新数据还是覆盖最旧数据一直有争论；两者都以数据完整性换取系统继续前进。
- Linux 面向 RT 的
printk改动很棘手；回移植甚至在某些发行版中引入了死锁。
日志记录、CAP 定理与“保证投递”
- 许多评论者将日志设计与 CAP 式权衡联系起来：你不可能同时拥有保证投递和对可用性零影响。
- “保证投递”的日志被认为适合审计/计费，但如果它会让服务停摆，就不可接受。
- 尽力而为的方案：本地队列、异步网络日志、mmap 的文件、通过 UDP 发往本地聚合器；在极端条件下最终都会丢日志。
- 有几位指出，“保证”往往实际上只是“极不可能丢失”，其上限受内存、磁盘或网络分区限制。
硬实时 vs 软实时，以及 RT Linux 的定位
- 有一个很强的区分：硬实时（错过截止时间 = 系统失效/安全风险）与软实时（偶尔错过 = 性能退化）。
- 普遍共识是，Linux 即使加上 PREEMPT_RT，也属于软实时：音频、视频、机器人控制层、工业设备、CNC 等。
- 安全关键的航电/医疗/汽车系统通常使用小型 RTOS 或 MCU；Linux 可能作为更高层控制器或 UI 与其并行存在。
- 有人认为专有 RTOS 栈会被取代；也有人认为认证复杂度和体积使 Linux 不适合许多安全关键角色。
实时性的硬件限制
- 现代 CPU 引入了无法界定上限的抖动来源：缓存、MMU、复杂总线、系统管理模式、不透明的内存控制器。
- “实时”被定义为“有界时间”；如果你无法界定内存访问或中断延迟，就不能真正算硬实时。
- 更简单的内核（8051、Cortex‑M/R）以及禁用缓存、锁定内存/核心、避免分页等技术，被提及为典型的硬实时做法。
微内核、替代 RTOS 与体系结构
- QNX、L4/seL4 之类的微内核，以及基于能力的系统，因其小而有界的内核和把驱动放在用户态而受到赞扬。
- 也有人指出 Linux 庞大的驱动生态在实践中具有巨大优势；微内核最终往往还是要把 Linux 当作 guest 来跑。
- 据报道，Xenomai 和双内核方案通过将 Linux 作为低优先级任务运行，提供了接近硬实时的行为。
对普通用户的影响
- 对普通用户来说，预期收益不算巨大但确实存在：在音频、游戏输入、视频会议中获得更低延迟和更小抖动，以及在负载下表现更好。
- 一些人希望发行版最终会默认提供支持 RT 的内核，因为在许多工作负载中，吞吐量影响被描述为很小。