【转载】为什么Linux不是实时操作系统 - 沐多 - 博客园

icon

password

new update day

URL

https://www.cnblogs.com/wsg1100/p/17985934

type

Post

status

Published

slug

2025/02/22/Why-Linux-is-not-a-real-time-operating-system

summary

Linux不是实时操作系统的原因包括中断响应时间和处理时间的不确定性、任务调度时机的不确定性，以及上下文切换的延迟。尽管有PREEMPT-RT等实时化方案，仍存在许多限制影响其实时性能。

一、什么是实时操作系统（RTOS）？

请参考本博客之前的文章：

简而言之，实时系统的核心在于响应事件的时间必须是确定的，而且绝对不能超过规定的期限。

二、linux为什么不是实时操作系统？

为了确保系统的实时性（即事件响应结果的时间准确性），我们可以将整个事件响应过程的延迟拆解为多个组成部分。只有当每个部分的响应时间都是确定的，整体的响应时间才能得到保证。

操作系统只能保证系统层面的时延，也就是实时任务的调度和执行。至于实时任务本身的执行时间是否确定，则取决于软件算法的设计，这直接影响最终结果输出的确定性。

对操作系统延时进行分解，可得出：系统延时=中断响应延时+中断处理延时+调度延时+进程切换延时。让我们逐一分析为什么Linux不是实时系统。

中断响应时间

💡

中断响应时间指从系统接收到中断信号，到进入中断服务例程开始执行的时间间隔。

在实时操作系统中，及时处理突发事件至关重要。中断机制作为事件响应和任务调度的触发点，其响应时间直接反映了系统的实时性能。因此，中断响应时间是衡量实时操作系统性能最关键的指标之一。

中断响应延迟由两部分组成：最大关中断时间和从硬件处理中断到执行中断服务程序第一条指令的时间。其中，关中断时间是影响这一指标的主要因素。

举个例子：当一个USB设备插入时，系统需要暂时关闭中断来处理这个新设备，如果此时恰好有一个高优先级的实时任务需要响应，就必须等待USB驱动完成初始化才能执行。

在 Linux 系统中，由于支持大量外设驱动且全球开发者众多，每个驱动程序的中断屏蔽时间都可能不同。这导致系统的中断响应时间无法准确预测，也就无法保证实时性。

中断处理时间

当系统响应中断后，会执行中断处理函数。Linux 系统中的中断处理延时具有不确定性，主要有两个原因：

Linux在执行中断处理时会关闭中断机制，且不支持中断嵌套；

各种硬件平台、外设类型和驱动程序的实现方式都会造成中断处理时间的差异。

任务调度延迟

当系统完成中断处理后，需要唤醒相应的任务进行处理。Linux采用多级调度策略，调度类按优先级从高到低排序为：最早截止时间优先（EDF）调度类、实时（RT）调度类、完全公平调度（CFS）类和空闲（IDLE）调度类。

尽管各调度类算法的时间复杂度都是O(1)，能够快速选择下一个要执行的任务，但Linux的实时性受限主要体现在调度时机的不确定性上。这种不确定性源于系统设计时需要在响应时间和系统性能之间做出权衡。

操作系统调度机制面临两个相互矛盾的设计目标：系统吞吐量和任务响应延迟。过于频繁的任务调度会导致大量CPU时间消耗在上下文切换上，反而降低系统的整体效率。

作为通用操作系统（GPOS），Linux优先考虑整体系统性能，追求较好的平均响应时间和系统吞吐量。每次上下文切换都需要保存和恢复处理器状态（包括寄存器内容）、切换内核栈和更新虚拟内存映射，这些操作都会占用宝贵的CPU时间。因此，在设计时需要谨慎选择调度点（即允许任务抢占的时机）。

调度器实质上是一个特定的程序模块，其触发执行的时机由系统的抢占模型决定。Linux主线内核目前实现了三种不同的抢占模型，每种模型都定义了各自的调度时机和抢占规则。

1、No Forced Preemption(Server)

早期Linux为追求最大吞吐量，只在内核态返回用户态时和中断处理返回用户态时进行调度。这意味着在整个内核态执行过程中都无法进行抢占。因此，从外部事件产生到P3任务执行的时间间隔可能变得非常长，完全丧失了时间确定性。

这种传统抢占模型专注于最大化吞吐量。虽然在大多数情况下可以提供较好的延迟性能，但无法保证响应时间的稳定性，容易出现长时间延迟。该模型主要用于服务器和科学计算系统。如果系统的首要目标是最大化内核处理能力，而不太关注调度延迟，就可以选择这种模型。

2、Voluntary Kernel Preemption(Desktop)

后来为了降低系统整体响应时间，Linux引入了自愿调度机制。内核开发者在开发驱动或子系统时，如果发现代码段占用CPU时间过长，可以主动调用might_resched()函数来添加抢占点，使其他任务有机会执行。与No Forced Preemption相比，这种方式显著缩短了P3事件的响应时间，同时几乎不影响系统吞吐量。

3、Preemptible Kernel(Low-Latency Desktop)

可抢占内核允许在内核态执行过程中，除了临界区外的所有内核代码都可被抢占。这种机制在现有基础上增加了中断处理返回内核态（内核态抢占）的抢占点。

该机制能够提供较低的响应延迟，即使在最坏情况下，延迟时间也仅为几毫秒。虽然这会稍微降低吞吐量并增加运行时开销，但与Voluntary Kernel Preemption相比，它显著缩短了从事件发生到高优先级P3任务开始运行的时间。

这种模型主要适用于对延迟要求在毫秒级的桌面系统和嵌入式系统（Linux 2.6及以上版本），其典型应用场景包括音视频处理。

为什么到这里Linux仍不是一个硬实时操作系统呢？这是因为在增加中断处理返回内核态的抢占点后，内核态中除了关中断的区域外，都可能发生抢占。这导致内核开发变得更加复杂——任何内核代码都需要考虑不同上下文下的重入和死锁问题，在多核环境下尤其如此。为了应对这些问题，系统不得不增加更多不可抢占的临界区。

因此，即使启用了可抢占内核，Linux的实时性能仍受到诸多限制：大量临界区和机制默认不可抢占（例如，内核态中超过10万处使用的自旋锁默认禁止抢占）、硬中断执行时间的不确定性，以及软中断总是抢占应用上下文等因素，这些都会影响任务调度的及时性。

4、Full Real Time Preemption(PREEMPT-RT)

也就是我们说的实时补丁，linux实时化的方案之一。

启用RT补丁（PREEMPT-RT）后可获得硬实时内核，使系统几乎在任何位置都能进行任务抢占。这种模型适用于对延迟要求为100微秒或更低（几十微秒）的实时系统。不过这也会降低系统吞吐量并增加运行时开销。

PREEMPT-RT自2004年推出以来，整合了多项关键技术：hrtimer、优先级翻转、可抢占RCU、中断线程化、Full Tickless和EDF调度等，以确保系统的整体实时性。目前超过90%的特性已被合并到主线内核中。

(1)仓库http://git.kernel.org/cgit/linux/kernel/git/rt/linux-rt-devel.git

(2)仓库http://git.kernel.org/cgit/linux/kernel/git/rt/linux-stable-rt.git

目前PREEMPT-RT已成为Linux实时增强的标准，未来将完全整合进Linux主线，无需额外打补丁。

Ubuntu于2022年10年推出了Ubuntu官方维护的preempt-rt分支，尝鲜详见【原创】Ubuntu Pro RealTime linux(Ubuntu22.04 安装PREEMPT-RT实时内核)

上下文切换时间

那么当下一个任务被选中后，Linux需要多久才能完成上下文切换？得益于现代CPU的针对性优化设计，Linux的上下文切换时间非常短，具体取决于处理器架构。

本文讨论了Linux不具备实时性的原因，并介绍了preempt-rt方案。除了preempt-rt，Linux还有其他实时化方案。下篇文章将介绍Linux的主流实时方案及其优缺点，感兴趣的读者可以参考实时linux方案概述

附

优先级翻转、可抢占RCU、

中断线程化原理及中断线程优先级配置

参考链接

Real-Time Linux Wiki

https://blog.csdn.net/fightingskyer/article/details/118877564

作者：wsg1100

出处：http://www.cnblogs.com/wsg1100/

本文版权归作者和博客园共有，欢迎转载，但必须给出原文链接，并保留此段声明，否则保留追究法律责任的权利。