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

标签：原创中断调度实时操作系统时间内核 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事件响应时间明显减少了，这种方式对吞吐量几乎没影响。