【原創】linux爲什麼不是實時操作系統

一、什麼是實時操作系統（RTOS）？

可參見本博客之前的文章：

總結一下，實時其實說的是系統響應事件需要的時間的確定性，時間必須確定，打死都不能超過這個時間。

二、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事件響應時間明顯減少了，這種方式對吞吐量幾乎沒影響。