前言

軟件工程師們總習(xí)慣把 OS （Operating System，操作系統(tǒng)）當(dāng)成是一個(gè)非常值得信賴的管家，我們只管把程序托管到OS上運(yùn)行，卻很少深入了解操作系統(tǒng)的運(yùn)行原理。

確實(shí)，OS作為一個(gè)通用的軟件系統(tǒng)，在大多數(shù)的場(chǎng)景下都表現(xiàn)得足夠的優(yōu)秀。但仍會(huì)有一些特殊的場(chǎng)景，需要我們對(duì)OS進(jìn)行各項(xiàng)調(diào)優(yōu)，才能讓業(yè)務(wù)系統(tǒng)更高效地完成任務(wù)。

這就要求我們必須深入了解OS的原理，不僅僅只會(huì)使喚這個(gè)管家，還能懂得如何讓管家做得更好 。

OS是一個(gè)非常龐大的軟件系統(tǒng)，本文主要探索其中的冰山一角： CPU的調(diào)度原理 。

說(shuō)起CPU的調(diào)度原理，很多人的第一反應(yīng)是基于時(shí)間片的調(diào)度，也即每個(gè)進(jìn)程都有占用CPU運(yùn)行的時(shí)間片，時(shí)間片用完之后，就讓出CPU給其他進(jìn)程。

至于OS是如何判斷一個(gè)時(shí)間片是否用完的、如何切換到另一個(gè)進(jìn)程等等更深層的原理，了解的人似乎并不多。

其實(shí)，基于時(shí)間片的調(diào)度只是眾多CPU的調(diào)度算法的一類，本文將會(huì)從最基礎(chǔ)的調(diào)度算法說(shuō)起，逐個(gè)分析各種主流調(diào)度算法的原理，帶大家一起探索CPU調(diào)度的奧秘。

CPU的上下文切換

在探索CPU調(diào)度原理之前，我們先了解一下CPU的上下文切換，它是CPU調(diào)度的基礎(chǔ)。

如今的OS幾乎都支持"同時(shí)"運(yùn)行遠(yuǎn)大于CPU數(shù)量的任務(wù)，OS會(huì)將CPU輪流分配給它們使用。

這就要求OS必須知道從哪里加載任務(wù)，以及加載后從哪里開始運(yùn)行，而這些信息都保存在CPU的寄存器中，其中即將執(zhí)行的下一條指令的地址被保存在 程序計(jì)數(shù)器 （PC）這一特殊寄存器上。 我們將寄存器的這些信息稱為CPU的上下文，也叫硬件上下文 。

OS在切換運(yùn)行任務(wù)時(shí)， 將上一任務(wù)的上下文保存下來(lái)，并將即將運(yùn)行的任務(wù)的上下文加載到CPU寄存器上的這一動(dòng)作，被稱為CPU上下文切換 。

CPU上下文屬于進(jìn)程上下文的一部分，我們常說(shuō)的進(jìn)程上下文由如下兩部分組成：

• 用戶級(jí)上下文 ：包含進(jìn)程的運(yùn)行時(shí)堆棧、數(shù)據(jù)塊、代碼塊等信息。
• 系統(tǒng)級(jí)上下文 ：包含進(jìn)程標(biāo)識(shí)信息、進(jìn)程現(xiàn)場(chǎng)信息（CPU上下文）、進(jìn)程控制信息等信息。

這涉及到兩個(gè)問(wèn)題：（1）上一任務(wù)的CPU上下文如何保存下來(lái)？（2）什么時(shí)候執(zhí)行上下文切換？

問(wèn)題1: 上一任務(wù)的CPU上下文如何保存下來(lái) ？

CPU上下文會(huì)被保存在進(jìn)程的 內(nèi)核空間 （kernel space）上。OS在給每個(gè)進(jìn)程分配虛擬內(nèi)存空間時(shí)，會(huì)分配一個(gè)內(nèi)核空間，這部分內(nèi)存只能由內(nèi)核代碼訪問(wèn)。

OS在切換CPU上下文前，會(huì)先將當(dāng)前CPU的通用寄存器、PC等進(jìn)程現(xiàn)場(chǎng)信息保存在進(jìn)程的內(nèi)核空間上，待下次切換時(shí)，再取出重新裝載到CPU上，以恢復(fù)任務(wù)的運(yùn)行。

問(wèn)題2: 什么時(shí)候執(zhí)行上下文切換 ？

OS要想進(jìn)行任務(wù)上下文切換，必須占用CPU來(lái)執(zhí)行切換邏輯。然而，用戶程序運(yùn)行的過(guò)程中，CPU已經(jīng)被用戶程序所占用，也即OS在此刻并未處于運(yùn)行狀態(tài)，自然也無(wú)法執(zhí)行上下文切換。針對(duì)該問(wèn)題，有兩種解決策略，協(xié)作式策略與搶占式策略。

協(xié)作式策略依賴用戶程序主動(dòng)讓出CPU，比如執(zhí)行系統(tǒng)調(diào)用（System Call）或者出現(xiàn)除零等異常。但該策略并不靠譜，如果用戶程序沒有主動(dòng)讓出CPU，甚至是惡意死循環(huán)，那么該程序?qū)?huì)一直占用CPU，唯一的恢復(fù)手段就是重啟系統(tǒng)了。

搶占式策略則依賴硬件的定時(shí)中斷機(jī)制（Timer Interrupt），OS會(huì)在初始化時(shí)向硬件注冊(cè)中斷處理回調(diào)（Interrupt Handler）。當(dāng)硬件產(chǎn)生中斷時(shí)，硬件會(huì)將CPU的處理權(quán)交給來(lái)OS，OS就可以在中斷回調(diào)上實(shí)現(xiàn)CPU上下文的切換。

調(diào)度的衡量指標(biāo)

對(duì)于一種CPU調(diào)度算法的好壞，一般都通過(guò)如下兩個(gè)指標(biāo)來(lái)進(jìn)行衡量：

• 周轉(zhuǎn)時(shí)間 （turnaround time），指從任務(wù)到達(dá)至任務(wù)完成之間的時(shí)間，即
• 響應(yīng)時(shí)間 （response time），指從任務(wù)到達(dá)至任務(wù)首次被調(diào)度的時(shí)間，即

兩個(gè)指標(biāo)從某種程度上是對(duì)立的，要求高的平均周轉(zhuǎn)時(shí)間，必然會(huì)降低平均響應(yīng)時(shí)間。具體追求哪種指標(biāo)與任務(wù)類型有關(guān)，比如程序編譯類的任務(wù)，要求周轉(zhuǎn)時(shí)間要小，盡可能快的完成編譯；用戶交互類的任務(wù)，則要求響應(yīng)時(shí)間要小，避免影響用戶體驗(yàn)。

工作負(fù)載假設(shè)

OS上的工作負(fù)載（也即各類任務(wù)運(yùn)行的狀況）總是千變?nèi)f化的，為了更好的理解各類CPU調(diào)度算法原理，我們先對(duì)工作負(fù)載進(jìn)行來(lái)如下幾種假設(shè)：

• 假設(shè)1 ：所有任務(wù)都運(yùn)行時(shí)長(zhǎng)都相同。
• 假設(shè)2 ：所有任務(wù)的開始時(shí)間都是相同的
• 假設(shè)3 ：一旦任務(wù)開始，就會(huì)一直運(yùn)行，直至任務(wù)完成。
• 假設(shè)4 ：所有任務(wù)只使用CPU資源（比如不產(chǎn)生I/O操作）。
• 假設(shè)5 ：預(yù)先知道所有任務(wù)的運(yùn)行時(shí)長(zhǎng)。

準(zhǔn)備工作已經(jīng)做好，下面我們開始進(jìn)入CPU調(diào)度算法的奇妙世界。

FIFO：先進(jìn)先出

FIFO（First In First Out，先進(jìn)先出）調(diào)度算法以原理簡(jiǎn)單，容易實(shí)現(xiàn)著稱，它 先調(diào)度首先到達(dá)的任務(wù)直至結(jié)束，然后再調(diào)度下一個(gè)任務(wù)，以此類推 。如果有多個(gè)任務(wù)同時(shí)到達(dá)，則隨機(jī)選一個(gè)。

在我們假設(shè)的工作負(fù)載狀況下，F(xiàn)IFO效率良好。比如有A、B、C三個(gè)任務(wù)滿足上述所有負(fù)載假設(shè)，每個(gè)任務(wù)運(yùn)行時(shí)長(zhǎng)為10s，在t=0時(shí)刻到達(dá)，那么任務(wù)調(diào)度情況是這樣的：

根據(jù)FIFO的調(diào)度原理，A、B、C分別在10、20、30時(shí)刻完成任務(wù)，平均周轉(zhuǎn)時(shí)間為20s（ ），效果很好。

然而現(xiàn)實(shí)總是殘酷的，如果假設(shè)1被打破，比如A的運(yùn)行時(shí)間變成100s，B和C的還是10s，那么調(diào)度情況是這樣的：

根據(jù)FIFO的調(diào)度原理，由于A的運(yùn)行時(shí)間過(guò)長(zhǎng)，B和C長(zhǎng)時(shí)間得不到調(diào)度，導(dǎo)致平均周轉(zhuǎn)時(shí)間惡化為110（ ）。

因此， FIFO調(diào)度策略在任務(wù)運(yùn)行時(shí)間差異較大的場(chǎng)景下，容易出現(xiàn)任務(wù)餓死的問(wèn)題 ！

針對(duì)這個(gè)問(wèn)題，如果運(yùn)行時(shí)間較短的B和C先被調(diào)度，問(wèn)題就可以解決了，這正是SJF調(diào)度算法的思想。

SJF：最短任務(wù)優(yōu)先

SJF（Shortest Job First，最短任務(wù)優(yōu)先） 從相同到達(dá)時(shí)間的多個(gè)任務(wù)中選取運(yùn)行時(shí)長(zhǎng)最短的一個(gè)任務(wù)進(jìn)行調(diào)度，接著再調(diào)度第二短的任務(wù)，以此類推 。

針對(duì)上一節(jié)的工作負(fù)載，使用SJF進(jìn)行調(diào)度的情況如下，周轉(zhuǎn)時(shí)間變成了50s（ ），相比FIFO的110s，有了2倍多的提升。

讓我們繼續(xù)打破 假設(shè)2 ，A在t=0時(shí)刻，B和C則在t=10時(shí)刻到達(dá)，那么調(diào)度情況會(huì)變成這樣：

因?yàn)槿蝿?wù)B和C比A后到，它們不得不一直等待A運(yùn)行結(jié)束后才有機(jī)會(huì)調(diào)度，即使A需要長(zhǎng)時(shí)間運(yùn)行。周轉(zhuǎn)時(shí)間惡化為103.33s（），再次出現(xiàn)任務(wù)餓死的問(wèn)題！

STCF：最短時(shí)間完成優(yōu)先

為了解決SJF的任務(wù)餓死問(wèn)題，我們需要打破 假設(shè)3 ，也即任務(wù)在運(yùn)行過(guò)程中是允許被打斷的。如果B和C在到達(dá)時(shí)就立即被調(diào)度，問(wèn)題就解決了。

這屬于搶占式調(diào)度，原理就是CPU上下文切換一節(jié)提到的，在中斷定時(shí)器到達(dá)之后，OS完成任務(wù)A和B的上下文切換。

我們?cè)趨f(xié)作式調(diào)度的SJF算法的基礎(chǔ)上，加上搶占式調(diào)度算法，就演變成了STCF算法（Shortest Time-to-Completion First，最短時(shí)間完成優(yōu)先），調(diào)度原理是 當(dāng)運(yùn)行時(shí)長(zhǎng)較短的任務(wù)到達(dá)時(shí)，中斷當(dāng)前的任務(wù)，優(yōu)先調(diào)度運(yùn)行時(shí)長(zhǎng)較短的任務(wù) 。

使用STCF算法對(duì)該工作負(fù)載進(jìn)行調(diào)度的情況如下，周轉(zhuǎn)時(shí)間優(yōu)化為50s（），再次解決了任務(wù)餓死問(wèn)題！

到目前為止，我們只關(guān)心了周轉(zhuǎn)時(shí)間這一衡量指標(biāo)，那么FIFO、SJF和STCF調(diào)度算法的響應(yīng)時(shí)間又是多長(zhǎng)呢？

不妨假設(shè)A、B、C三個(gè)任務(wù)都在t=0時(shí)刻到達(dá)，運(yùn)行時(shí)長(zhǎng)都是5s，那么這三個(gè)算法的調(diào)度情況如下，平均響應(yīng)時(shí)長(zhǎng)為5s（）：

更糟糕的是，隨著任務(wù)運(yùn)行時(shí)長(zhǎng)的增長(zhǎng)，平均響應(yīng)時(shí)長(zhǎng)也隨之增長(zhǎng)，這對(duì)于交互類任務(wù)來(lái)說(shuō)將會(huì)是災(zāi)難性的，嚴(yán)重影響用戶體驗(yàn)。

該問(wèn)題的根源在于，當(dāng)任務(wù)都同時(shí)到達(dá)且運(yùn)行時(shí)長(zhǎng)相同時(shí)，最后一個(gè)任務(wù)必須等待其他任務(wù)全部完成之后才開始調(diào)度。

為了優(yōu)化響應(yīng)時(shí)間，我們熟悉的基于時(shí)間片的調(diào)度出現(xiàn)了。

RR：基于時(shí)間片的輪詢調(diào)度

RR（Round Robin，輪訓(xùn)）算法給每個(gè)任務(wù)分配一個(gè)時(shí)間片，當(dāng)任務(wù)的時(shí)間片用完之后，調(diào)度器會(huì)中斷當(dāng)前任務(wù)，切換到下一個(gè)任務(wù)，以此類推 。

需要注意的是，時(shí)間片的長(zhǎng)度設(shè)置必須是中斷定時(shí)器的整數(shù)倍，比如中斷定時(shí)器時(shí)長(zhǎng)為2ms，那么任務(wù)的時(shí)間片可以設(shè)置為2ms、4ms、6ms ... 否則即使任務(wù)的時(shí)間片用完之后，定時(shí)中斷沒發(fā)生，OS也無(wú)法切換任務(wù)。

現(xiàn)在，使用RR進(jìn)行調(diào)度，給A、B、C分配一個(gè)1s的時(shí)間片，那么調(diào)度情況如下，平均響應(yīng)時(shí)長(zhǎng)為1s（）：

從RR的調(diào)度原理可以發(fā)現(xiàn)，把時(shí)間片設(shè)置得越小，平均響應(yīng)時(shí)間也越小。但隨著時(shí)間片的變小，任務(wù)切換的次數(shù)也隨之上升，也就是上下文切換的消耗會(huì)變大。

因此，時(shí)間片大小的設(shè)置是一個(gè)trade-off的過(guò)程，不能一味追求響應(yīng)時(shí)間而忽略CPU上下文切換帶來(lái)的消耗。

CPU上下文切換的消耗，不只是保存和恢復(fù)寄存器所帶來(lái)的消耗。程序在運(yùn)行過(guò)程中，會(huì)逐漸在CPU各級(jí)緩存、TLB、分支預(yù)測(cè)器等硬件上建立屬于自己的緩存數(shù)據(jù)。當(dāng)任務(wù)被切換后，就意味著又得重來(lái)一遍緩存預(yù)熱，這會(huì)帶來(lái)巨大的消耗。

另外，RR調(diào)度算法的周轉(zhuǎn)時(shí)間為14s（），相比于FIFO、SJF和STCF的10s（）差了不少。

這也驗(yàn)證了之前所說(shuō)的，周轉(zhuǎn)時(shí)間和響應(yīng)時(shí)間在某種程度上是對(duì)立的，如果想要優(yōu)化周轉(zhuǎn)時(shí)間，建議使用SJF和STCF；如果想要優(yōu)化響應(yīng)時(shí)間，則建議使用RR。

I/O操作對(duì)調(diào)度的影響

到目前為止，我們并未考慮任何的I/O操作。我們知道，當(dāng)觸發(fā)I/O操作時(shí)，進(jìn)程并不會(huì)占用CPU，而是阻塞等待I/O操作的完成。

現(xiàn)在讓我們打破 假設(shè)4 ，考慮任務(wù)A和B都在t=0時(shí)刻到達(dá)，運(yùn)行時(shí)長(zhǎng)都是50ms，但A每隔10ms執(zhí)行一次阻塞10ms的I/O操作，而B沒有I/O。

如果使用STCF進(jìn)行調(diào)度，調(diào)度的情況是這樣的：

從上圖看出，任務(wù)A和B的調(diào)度總時(shí)長(zhǎng)達(dá)到了140ms，比實(shí)際A和B運(yùn)行時(shí)長(zhǎng)總和100ms要大。而且A阻塞在I/O操作期間，調(diào)度器并沒有切換到B，導(dǎo)致了CPU的空轉(zhuǎn)！

要解決該問(wèn)題，只需使用RR的調(diào)度算法，給任務(wù)A和B分配10ms的時(shí)間片，這樣當(dāng)A阻塞在I/O操作時(shí)，就可以調(diào)度B，而B用完時(shí)間片后，恰好A也從I/O阻塞中返回，以此類推，調(diào)度總時(shí)長(zhǎng)優(yōu)化至100ms。

該調(diào)度方案是建立在假設(shè)5之上的，也即要求調(diào)度器預(yù)先知道A和B的運(yùn)行時(shí)長(zhǎng)、I/O操作時(shí)間長(zhǎng)等信息，才能如此充分地利用CPU。

然而，實(shí)際的情況遠(yuǎn)比這復(fù)雜，I/O阻塞時(shí)長(zhǎng)不會(huì)每次都一樣，調(diào)度器也無(wú)法準(zhǔn)確知道A和B的運(yùn)行信息。當(dāng)假設(shè)5也被打破時(shí)，調(diào)度器又該如何實(shí)現(xiàn)才能最大程度保證CPU利用率，以及調(diào)度的合理性呢？

接下來(lái)，我們將介紹一個(gè)能夠在所有工作負(fù)載假設(shè)被打破的情況下依然表現(xiàn)良好，被許多現(xiàn)代操作系統(tǒng)采用的CPU調(diào)度算法，MLFQ。

MLFQ：多級(jí)反饋隊(duì)列

MLFQ（Multi-Level Feedback Queue，多級(jí)反饋隊(duì)列）調(diào)度算法的目標(biāo)如下：

1. 優(yōu)化周轉(zhuǎn)時(shí)間。
2. 降低交互類任務(wù)的響應(yīng)時(shí)間，提升用戶體驗(yàn)。

從前面分析我們知道，要優(yōu)化周轉(zhuǎn)時(shí)間，可以優(yōu)先調(diào)度運(yùn)行時(shí)長(zhǎng)短的任務(wù)（像SJF和STCF的做法）；要優(yōu)化響應(yīng)時(shí)間，則采用類似RR的基于時(shí)間片的調(diào)度。然而，這兩個(gè)目標(biāo)看起來(lái)是矛盾的，要降低響應(yīng)時(shí)間，必然會(huì)增加周轉(zhuǎn)時(shí)間。

那么對(duì)MLFQ來(lái)說(shuō)，就需要解決如下兩個(gè)問(wèn)題：

1. 在不預(yù)先清楚任務(wù)的運(yùn)行信息（包括運(yùn)行時(shí)長(zhǎng)、I/O操作等）的前提下，如何權(quán)衡周轉(zhuǎn)時(shí)間和響應(yīng)時(shí)間？
2. 如何從歷史調(diào)度中學(xué)習(xí)，以便未來(lái)做出更好的決策？

劃分任務(wù)的優(yōu)先級(jí)

MLFQ與前文介紹的幾種調(diào)度算法最顯著的特點(diǎn)就是新增了優(yōu)先級(jí)隊(duì)列存放不同優(yōu)先級(jí)的任務(wù)，并定下了如下兩個(gè)規(guī)則：

• 規(guī)則1 ：如果Priority(A) > Priority(B)，則調(diào)度A
• 規(guī)則2 ：如果Priority(A) = Priority(B)，則按照RR算法調(diào)度A和B

優(yōu)先級(jí)的變化

MLFQ必須考慮改變?nèi)蝿?wù)的優(yōu)先級(jí)，否則根據(jù) 規(guī)則1 和 規(guī)則2 ，對(duì)于上圖中的任務(wù)C，在A和B運(yùn)行結(jié)束之前，C都不會(huì)獲得運(yùn)行的機(jī)會(huì)，導(dǎo)致C的響應(yīng)時(shí)間很長(zhǎng)。因此，可以定下了如下幾個(gè)優(yōu)先級(jí)變化規(guī)則：

• 規(guī)則3 ：當(dāng)一個(gè)新的任務(wù)到達(dá)時(shí)，將它放到最高優(yōu)先級(jí)隊(duì)列中
• 規(guī)則4a ：如果任務(wù)A運(yùn)行了一個(gè)時(shí)間片都沒有主動(dòng)讓出CPU（比如I/O操作），則優(yōu)先級(jí)降低一級(jí)
• 規(guī)則4b ：如果任務(wù)A在時(shí)間片用完之前，有主動(dòng)讓出CPU，則優(yōu)先級(jí)保持不變

規(guī)則3主要考慮到讓新加入的任務(wù)都能得到調(diào)度機(jī)會(huì)，避免出現(xiàn)任務(wù)餓死的問(wèn)題

規(guī)則4a和4b主要考慮到，交互類任務(wù)大都是short-running的，并且會(huì)頻繁讓出CPU，因此為了保證響應(yīng)時(shí)間，需要保持現(xiàn)有的優(yōu)先級(jí)；而CPU密集型任務(wù)，往往不會(huì)太關(guān)注響應(yīng)時(shí)間，因此可以降低優(yōu)先級(jí)。

按照上述規(guī)則，當(dāng)一個(gè)long-running任務(wù)A到達(dá)時(shí)，調(diào)度情況是這樣的：

如果在任務(wù)A運(yùn)行到t=100時(shí)，short-time任務(wù)B到達(dá)，調(diào)度情況是這樣的：

從上述調(diào)度情況可以看出，MLFQ具備了STCF的優(yōu)點(diǎn)，即可以優(yōu)先完成short-running任務(wù)的調(diào)度，縮短了周轉(zhuǎn)時(shí)間。

如果任務(wù)A運(yùn)行到t=100時(shí)，交互類任務(wù)C到達(dá)，那么調(diào)度情況是這樣的：

MLFQ會(huì)在任務(wù)處于阻塞時(shí)按照優(yōu)先級(jí)選擇其他任務(wù)運(yùn)行，避免CPU空轉(zhuǎn) 。因此，在上圖中，當(dāng)任務(wù)C處于I/O阻塞狀態(tài)時(shí)，任務(wù)A得到了運(yùn)行時(shí)間片，當(dāng)任務(wù)C從I/O阻塞上返回時(shí)，A再次掛起，以此類推。

另外，因?yàn)槿蝿?wù)C在時(shí)間片之內(nèi)出現(xiàn)主動(dòng)讓出CPU的行為，C的優(yōu)先級(jí)一直保持不變，這對(duì)于交互類任務(wù)而言，有效提升了用戶體驗(yàn)。

CPU密集型任務(wù)餓死問(wèn)題

到目前為止，MLFQ似乎能夠同時(shí)兼顧周轉(zhuǎn)時(shí)間，以及交互類任務(wù)的響應(yīng)時(shí)間，它真的完美了嗎？

考慮如下場(chǎng)景，任務(wù)A運(yùn)行到t=100時(shí)，交互類任務(wù)C和D同時(shí)到達(dá)，那么調(diào)度情況會(huì)是這樣的：

由此可見，如果當(dāng)前系統(tǒng)上存在很多交互類任務(wù)時(shí)，CPU密集型任務(wù)將會(huì)存在餓死的可能！

為了解決該問(wèn)題，可以設(shè)立了如下規(guī)則：

• 規(guī)則5 ：系統(tǒng)運(yùn)行S時(shí)長(zhǎng)之后，將所有任務(wù)放到最高優(yōu)先級(jí)隊(duì)列上（ Priority Boost ）

加上該規(guī)則之后，假設(shè)設(shè)置S為50ms，那么調(diào)度情況是這樣的，餓死問(wèn)題得到解決！

惡意任務(wù)問(wèn)題

考慮如下一個(gè)惡意任務(wù)E，為了長(zhǎng)時(shí)間占用CPU，任務(wù)E在時(shí)間片還剩1%時(shí)故意執(zhí)行I/O操作，并很快返回。根據(jù) 規(guī)則4b ，E將會(huì)維持在原來(lái)的最高優(yōu)先級(jí)隊(duì)列上，因此下次調(diào)度時(shí)仍然獲得調(diào)度優(yōu)先權(quán)：

為了解決該問(wèn)題，我們需要將規(guī)則4調(diào)整為如下規(guī)則：

• 規(guī)則4 ：給每個(gè)優(yōu)先級(jí)分配一個(gè)時(shí)間片，當(dāng)任務(wù)用完該優(yōu)先級(jí)的時(shí)間片后，優(yōu)先級(jí)降一級(jí)

應(yīng)用新的規(guī)則4后，相同的工作負(fù)載，調(diào)度情況變成了如下所述，不再出現(xiàn)惡意任務(wù)E占用大量CPU的問(wèn)題。

到目前為止，MLFQ的基本原理已經(jīng)介紹完，最后，我們總結(jié)下MLFQ最關(guān)鍵的5項(xiàng)規(guī)則：

• 規(guī)則1 ：如果Priority(A) > Priority(B)，則調(diào)度A
• 規(guī)則2 ：如果Priority(A) = Priority(B)，則按照RR算法調(diào)度A和B
• 規(guī)則3 ：當(dāng)一個(gè)新的任務(wù)到達(dá)時(shí)，將它放到最高優(yōu)先級(jí)隊(duì)列中
• 規(guī)則4 ：給每個(gè)優(yōu)先級(jí)分配一個(gè)時(shí)間片，當(dāng)任務(wù)用完該優(yōu)先級(jí)的時(shí)間片后，優(yōu)先級(jí)降一級(jí)
• 規(guī)則5 ：系統(tǒng)運(yùn)行S時(shí)長(zhǎng)之后，將所有任務(wù)放到最高優(yōu)先級(jí)隊(duì)列上（ Priority Boost ）

現(xiàn)在，再回到本節(jié)開始時(shí)提出的兩個(gè)問(wèn)題：

1、在不預(yù)先清楚任務(wù)的運(yùn)行信息（包括運(yùn)行時(shí)長(zhǎng)、I/O操作等）的前提下，MLFQ如何權(quán)衡周轉(zhuǎn)時(shí)間和響應(yīng)時(shí)間 ？

在預(yù)先不清楚任務(wù)到底是long-running或short-running的情況下，MLFQ會(huì)先假設(shè)任務(wù)屬于shrot-running任務(wù)，如果假設(shè)正確，任務(wù)就會(huì)很快完成，周轉(zhuǎn)時(shí)間和響應(yīng)時(shí)間都得到優(yōu)化；即使假設(shè)錯(cuò)誤，任務(wù)的優(yōu)先級(jí)也能逐漸降低，把更多的調(diào)度機(jī)會(huì)讓給其他short-running任務(wù)。

2、MLFQ如何從歷史調(diào)度中學(xué)習(xí)，以便未來(lái)做出更好的決策 ？

MLFQ主要根據(jù)任務(wù)是否有主動(dòng)讓出CPU的行為來(lái)判斷其是否是交互類任務(wù)，如果是，則維持在當(dāng)前的優(yōu)先級(jí)，保證該任務(wù)的調(diào)度優(yōu)先權(quán)，提升交互類任務(wù)的響應(yīng)性。

當(dāng)然，MLFQ并非完美的調(diào)度算法，它也存在著各種問(wèn)題，其中最讓人困擾的就是MLFQ各項(xiàng)參數(shù)的設(shè)定，比如優(yōu)先級(jí)隊(duì)列的數(shù)量，時(shí)間片的長(zhǎng)度、Priority Boost的間隔等。

這些參數(shù)并沒有完美的參考值，只能根據(jù)不同的工作負(fù)載來(lái)進(jìn)行設(shè)置。

比如，我們可以將低優(yōu)先級(jí)隊(duì)列上任務(wù)的時(shí)間片設(shè)置長(zhǎng)一些，因?yàn)榈蛢?yōu)先級(jí)的任務(wù)往往是CPU密集型任務(wù)，它們不太關(guān)心響應(yīng)時(shí)間，較長(zhǎng)的時(shí)間片長(zhǎng)能夠減少上下文切換帶來(lái)的消耗。

CFS：Linux的完全公平調(diào)度

本節(jié)我們將介紹一個(gè)平時(shí)打交道最多的調(diào)度算法，Linux系統(tǒng)下的CFS（Completely Fair Scheduler，完全公平調(diào)度）。與上一節(jié)介紹的MLFQ不同， CFS并非以優(yōu)化周轉(zhuǎn)時(shí)間和響應(yīng)時(shí)間為目標(biāo)，而是希望將CPU公平地均分給每個(gè)任務(wù) 。

當(dāng)然，CFS也提供了給進(jìn)程設(shè)置優(yōu)先級(jí)的功能，讓用戶/管理員決定哪些進(jìn)程需要獲得更多的調(diào)度時(shí)間。

基本原理

大部分調(diào)度算法都是基于固定時(shí)間片來(lái)進(jìn)行調(diào)度，而CFS另辟蹊徑，采用基于計(jì)數(shù)的調(diào)度方法，該技術(shù)被稱為 virtual runtime 。

CFS給每個(gè)任務(wù)都維護(hù)一個(gè)vruntime值，每當(dāng)任務(wù)被調(diào)度之后，就累加它的vruntime。

比如，當(dāng)任務(wù)A運(yùn)行了5ms的時(shí)間片之后，則更新為vruntime += 5ms。 CFS在下次調(diào)度時(shí)，選擇vruntime值最小的任務(wù)來(lái)調(diào)度 ，比如：

那CFS應(yīng)該什么時(shí)候進(jìn)行任務(wù)切換呢？切換得頻繁些，任務(wù)的調(diào)度會(huì)更加的公平，但是上下文切換帶來(lái)的消耗也越大。因此，CFS給用戶提供了個(gè)可配參數(shù)sched_latency，讓用戶來(lái)決定切換的時(shí)機(jī)。

CFS將每個(gè)任務(wù)分到的時(shí)間片設(shè)置為 time_slice = sched_latency / n（n為當(dāng)前的任務(wù)數(shù)） ，以確保在sched_latency周期內(nèi)，各任務(wù)能夠均分CPU，保證公平性。

比如將sched_latency設(shè)置為48ms，當(dāng)前有4個(gè)任務(wù)A、B、C和D，那么每個(gè)任務(wù)分到的時(shí)間片為12ms；后面C和D結(jié)束之后，A和B分到的時(shí)間片也更新為24ms：

從上述原理上看，在sched_latency 不變的情況下，隨著系統(tǒng)任務(wù)數(shù)的增加，每個(gè)任務(wù)分到的時(shí)間片也隨之減少，任務(wù)切換所帶來(lái)的消耗也會(huì)增大。為了避免過(guò)多的任務(wù)切換消耗，CFS提供了可配參數(shù)min_granularity來(lái)設(shè)置任務(wù)的最小時(shí)間片。

比如sched_latency設(shè)置為48ms，min_granularity設(shè)置為 6ms，那么即使當(dāng)前任務(wù)數(shù)有12，每個(gè)任務(wù)數(shù)分到的時(shí)間片也是6ms，而不是4ms。

給任務(wù)分配權(quán)重

有時(shí)候，我們希望給系統(tǒng)中某個(gè)重要的業(yè)務(wù)進(jìn)程多分配些時(shí)間片，而其他不重要的進(jìn)程則少分配些時(shí)間片。但按照上一節(jié)介紹的基本原理，使用CFS調(diào)度時(shí)，每個(gè)任務(wù)都是均分CPU的，有沒有辦法可以做到這一點(diǎn)呢？

可以給任務(wù)分配權(quán)重，讓權(quán)重高的任務(wù)更多的CPU ！

加上權(quán)重機(jī)制后，任務(wù)時(shí)間片的計(jì)算方式變成了這樣：

比如，sched_latency還是設(shè)置為48ms，現(xiàn)有A和B兩個(gè)任務(wù)，A的權(quán)重設(shè)置為1024，B的權(quán)重設(shè)置為3072，按照上述的公式，A的時(shí)間片是12ms，B的時(shí)間片是36ms。

從上一節(jié)可知，CFS每次選取vruntime值最小的任務(wù)來(lái)調(diào)度，而每次調(diào)度完成后，vruntime的計(jì)算規(guī)則為vruntime += runtime，因此僅僅改變時(shí)間片的計(jì)算規(guī)則不會(huì)生效，還需將vruntime的計(jì)算規(guī)則調(diào)整為：

還是前面的例子，假設(shè)A和B都沒有I/O操作，更新vruntime計(jì)算規(guī)則后，調(diào)度情況如下，任務(wù)B比任務(wù)A能夠分得更多的CPU了。

使用紅黑樹提升vruntime查找效率

CFS每次切換任務(wù)時(shí)，都會(huì)選取vruntime值最小的任務(wù)來(lái)調(diào)度，因此需要它有個(gè)數(shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)各個(gè)任務(wù)及其vruntime信息。

最直觀的當(dāng)然就是選取一個(gè)有序列表來(lái)存儲(chǔ)這些信息，列表按照vruntime排序。這樣在切換任務(wù)時(shí)，CFS只需獲取列表頭的任務(wù)即可，時(shí)間復(fù)雜度為O(1)。

比如當(dāng)前有10個(gè)任務(wù)，vruntime保存為有序鏈表[1, 5, 9, 10, 14, 18, 17, 21, 22, 24]，但是每次插入或刪除任務(wù)時(shí)，時(shí)間復(fù)雜度會(huì)是O(N)，而且耗時(shí)隨著任務(wù)數(shù)的增多而線性增長(zhǎng)！

為了兼顧查詢、插入、刪除的效率，CFS使用紅黑樹來(lái)保存任務(wù)和vruntime信息，這樣，查詢、插入、刪除操作的復(fù)雜度變成了log(N)，并不會(huì)隨著任務(wù)數(shù)的增多而線性增長(zhǎng)，極大提升了效率。

另外，為了提升存儲(chǔ)效率，CFS在紅黑樹中只保存了處于Running狀態(tài)的任務(wù)的信息。

應(yīng)對(duì)I/O與休眠

每次都選取vruntime值最小的任務(wù)來(lái)調(diào)度這種策略，也會(huì)存在任務(wù)餓死的問(wèn)題?？紤]有A和B兩個(gè)任務(wù)，時(shí)間片為1s，起初A和B均分CPU輪流運(yùn)行，在某次調(diào)度后，B進(jìn)入了休眠，假設(shè)休眠了10s。

等B醒來(lái)后，就會(huì)比小10s，在接下來(lái)的10s中，B將會(huì)一直被調(diào)度，從而任務(wù)A出現(xiàn)了餓死現(xiàn)象。

為了解決該問(wèn)題，CFS規(guī)定當(dāng)任務(wù)從休眠或I/O中返回時(shí)，該任務(wù)的vruntime會(huì)被設(shè)置為當(dāng)前紅黑樹中的最小vruntime值。上述例子，B從休眠中醒來(lái)后，會(huì)被設(shè)置為11，因此也就不會(huì)餓死任務(wù)A了。

這種做法其實(shí)也存在瑕疵，如果任務(wù)的休眠時(shí)間很短，那么它醒來(lái)后依舊是優(yōu)先調(diào)度，這對(duì)于其他任務(wù)來(lái)說(shuō)是不公平的。

寫在最后

本文花了很長(zhǎng)的篇幅講解了幾種常見CPU調(diào)度算法的原理，每種算法都有各自的優(yōu)缺點(diǎn)，并不存在一種完美的調(diào)度策略。在應(yīng)用中，我們需要根據(jù)實(shí)際的工作負(fù)載，選取合適的調(diào)度算法，配置合理的調(diào)度參數(shù)，權(quán)衡周轉(zhuǎn)時(shí)間和響應(yīng)時(shí)間、任務(wù)公平和切換消耗。

這些都應(yīng)驗(yàn)了《Fundamentals of Software Architecture》中的那句名言： Everything in software architecture is a trade-off .

本文中描述的調(diào)度算法都是基于單核處理器進(jìn)行分析的，而多核處理器上的調(diào)度算法要比這復(fù)雜很多，比如需要考慮處理器之間共 享數(shù)據(jù)同步 、緩存親和性等，但本質(zhì)原理依然離不開本文所描述的幾種基礎(chǔ)調(diào)度算法。