【原创】linux为什么不是实时操作系统

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

可参见本博客之前的文章：

什么是实时

实时的分类

常见的RTOS

latency和jitter

总结一下，实时其实说的是系统响应事件需要的时间的确定性，时间必须确定，打死都不能超过这个时间。

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

为了确保系统的实时性，即事件响应产生结果的时间准确性，可以将整个事件响应过程的延迟拆解为若干个组成部分如下。只有各个部分的响应时间都具有确定性，整体的响应时间才能得到保证。

而操作系统仅能保证系统层面时延，也就是完成实时任务的调度执行，至于你的实时任务执行时间确不确定，还取决于你的软件算法设计，然后输出计算或控制结果，即最后结果输出的确定性。

对操作系统延时进行分解，可分解为系统延时=中断响应延时+中断处理延时+调度延时+进程切换延时，所以我们一一来看，linux为什么不实时？

中断响应时间

中断响应时间是指从接收到中断信号到操作系统做出响应，并完成进入中断服务例程所需要的时间。

实时操作系统的意义就在于能够在确定的时间内处理各种突发的事件，而中断是这些事件、系统抢占调度的触发点，中断何时得到处理反应了系统的基本实时性能，因而衡量嵌入式实时操作系统的最主要、最具有代表性的性能指标参数无疑是中断响应时间。

中断延迟时间＝最大关中断时间＋硬件开始处理中断到开始执行中断服务例程第一条指令之间的时间。通俗地说：中断产生到内核执行中断处理程序第一条指令的时间。影响该指标的最大因素是中断屏蔽时间。

那么任何条件下，linux中断响应时间确定吗（也就是最大中断屏蔽时间确定吗）？全球这么多开发者一起开发，linux支持这么多外设驱动，谁的驱动屏蔽中断执行多久谁知道呢？

中断处理时间

响应中断后，开始执行中断处理函数，不同的中断处理所需要的时间不同，那linux的中断处理延时确定吗？Linux由于不支持中断嵌套，执行中断处理时关中断，所以，该时间同样未知！不同的板子，不同的外设，不同的驱动程序设计，中断处理需要的时间均不一样。

任务调度时间

那一个事件产生，完成中断处理，下一步唤醒与该事件相关的任务。现在要找到下一个使用cpu的任务，如果系统中有成千上万个任务，linux从中选择运行的任务的时间要多少，这个调度过程的时间确定吗？服务器托管网 这就是为什么要有不同调度类和调度算法，不同调度类之间还要有不同的优先级，EDF调度类>RT调度类>完全公平调度调度类>idle调度类。Linux不同调度类的调度算法时间复杂度为O(1)，选择下一个运行的任务很快，所以linux的实时问题不是出在这，而是什么时候能调度的问题！！！

任何操作系统的调度追求2个目标：吞吐率大和延迟低，但这个目标是相互矛盾的。调度和上下文切换过程本身也是要CPU时间的，频繁的上下文切换会导致CPU时间的浪费，降低系统的吞吐量，

Linux是通用操作系统(GPOS), 其定位是尽量缩短系统的平均响应时间，提高吞吐量，注重操作系统的整体功能需求，达到更好的平均性能。（过度追求响应时，过多的上下文切换把 CPU 时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上，从而缩短进程真正运行的时间，导致系统的整体性能大幅下降），所以规定在哪可以调度很重要，也就是我们说的调度点或者抢占点。

说白了，调度也是一段代码，一个函数，什么时候可以调用这个函数呢？不同的抢占模型抢占点不同，目前linux主线提供了3种抢占模型。

1、No Forced Preemption(Server)

早期linux为追求最大吞吐量，只能在内核态返回用户态时 和中断处理返回用户态时进行调度，也就是整个内核态执行的过程中都不能抢占，那外部事件产服务器托管网生到p3任务执行，这时间就可大了去了，完全没有确定性可言。

这是传统的抢占模型，目标是使吞吐量最大化。大多数时候提供良好的延迟，但是没有保证，可能偶尔出现长的延迟。这种模型主要用于服务器和科学计算系统。如果希望使内核的处理能力最大化，不考虑调度延迟，那么应该选择这种模型。

2、Voluntary Kernel Preemption(Desktop)

后来呢，为降低系统整体的响应时间，加入了自愿调度，也就是我是内核开发者，我在开发这个驱动或者子系统的时候，我觉得这里我占用CPU太久了，我主动加一行代码调用might_resched()增加抢占点，让别的任务执行一下，相比No Forced Preemption P3事件响应时间明显减少了，这种方式对吞吐量几乎没影响。

3、Preemptible Kernel(Low-Latency Desktop)

可抢占内核，就是内核态执行过程中，除了临界区以外的所有内核代码可抢占，也就是在上面的基础上增加了中断处理返回内核态(内核态抢占)的抢占点。

提供了很低的响应延迟，最坏情况的延迟时间是几毫秒，代价是稍微降低吞吐量和稍微增加运行时开销。相比Voluntary Kernel Preemption，从事件发生到高优先级的p3到得到运行之间的时间更少了。

这种模型主要用于有毫秒级别延迟需求的桌面系统和嵌入式系统（linux 2.6 以上），比如音视频处理。

那为什么到这linux还不是一个硬实时操作系统呢？因为增加了中断处理返回内核态的抢占点，内核态中，只要不是关中断的地方，都可能发生抢占，这时候内核开发就变复杂了，任何内核代码都要考虑不同的上下文会不会有重入/死锁问题，多核下死锁的问题，进而增加了更多的临界区，这些临界区是不能抢占的。

所以就算linux启用可抢占内核，还有很多临界区和机制是默认不能抢占的，spinlock默认禁止抢占（整个内核态有10万+地方使用），同时硬中断的执行时间不确定，软中断总是抢占应用上下文等等影响任务调度时间的地方。

4、Full Real Time Preemption(PREEMPT-RT)

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

使能RT补丁，得到硬实时kernel，几乎任何地方都可以发生抢占，这种模型主要用于延迟要求为100微秒或稍低（几十微秒）的实时系统。 降低吞吐量、增加更多运行时开销。

PREEMPT-RT包含了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

上下文切换时间

那下一个运行的任务选出来了，linux完成上下文切换需要多久？得益于现在的CPU针对性优化设计，linux上下文切换时间是很短的，与处理器架构相关。

下篇文章介绍Linux实时方案，详见实时linux方案概述

参考链接

Real-Time Linux Wiki

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

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net

相关推荐: MiniMax 国内首个MoE大语言模型全量上线啦

MiniMax 国内首个 MoE 大语言模型全量上线啦 今天，经过了半个月的部分客户的内测和反馈，MiniMax 全量发布大语言模型 abab6，为国内首个 MoE 大语言模型。在 MoE 结构下，abab6 拥有大参数带来的处理复杂任务的能力，同时模型在单位…