操做系統導論（2）

進程的調度

• 考慮因素

  1. 爲了構建調度策略，須要作一些簡化假設，這些假設和系統中運行的進程相關，統稱爲工做負載(workload)

     （1）每個進程（工做）運行相同的時間

     （2）全部工做同時到達，有時候當多個工做到達的時間相差很小的時候，也近似認爲是同時到達的

     （3）一旦開始工做，每一個工做將保持運行直到完成

     （4）全部工做只是使用CPU，即：它們不執行I/O操做

     （5）每一個工做的運行時間是已知的

  2. 爲了可以衡量不一樣調度策略的優缺點，提出一個指標——週轉時間（turnaround time)

     （1）定義：任務完成時間減去任務到達的時間，即：

（2）當知足假設同時到達時，到達時間爲0，週轉時間等於完成時間

 （3）週轉時間是一個**性能**（performance）**指標**。而性能和公平在調度系統每每時矛盾的。調度系統能夠優化性能，但代價時阻止一些任務運行，這就下降了公平

• 先進先出（FIFO）

  1. 先進先出（First In First Out)：先就緒的工做先執行

  2. 假設有A、B、C三個工做，A比B早一點點，B比C早一點點，此時根據咱們的假設，能夠將A、B、C近似看做時同時到達的。可是根據實際狀況，是A先執行，其次是B，最後是C。假設每一個工做運行10s，求工做的平均週轉時間（average turnaround time)？
     

     A的週轉時間爲10s，B的週轉時間爲20s，C的週轉時間爲30s

     平均週轉時間爲（10+20+30）/3=20

  3. 如今放寬假設1，讓A、B、C運行時間不一樣，考慮FIFO是否存在平均週轉時間較長的狀況

  4. 假設A、B、C三個工做，A運行時間爲100s，B和C運行時間爲10s，若是依舊是A先早到一點，而後是B，最後是C（仍然近似認爲是同時到達的），此時系統的平均週轉時間較長（100+110+120）/3=110

  5. FIFO出現4這種狀況被稱爲護航效應（convoy effect），即：一些耗時較少的潛在資源消耗者排在重量級的資源消費者後面。例如：在雜貨店只有一個排隊隊伍的時候，你看見前面的裝滿了3輛購物車的貨物時，這會讓你等很長時間

• 最短任務優先（SJF）

  1. 最短任務優先（Shortest Job First）：先運行最短的時間，而後是次短的時間，如此繼續

  2. 依舊在上述4的狀況下，按照SJF的策略，平均週轉時間爲（10+20+120）/3=50，和FIFO相比，顯著下降了平均週轉時間。但前提是知足假設2——同時到達
     

  3. 如今放寬假設2，即：工做可以隨時到達，考慮SJF平均週轉時間較長的狀況

  4. 依舊是FIFO中4的狀況，假設A在t=0時到達，而且須要運行100s，而B和C在t=10s到達，各自運行10s。則A的週轉時間爲100s，B的週轉時間爲110-10=100，C的週轉時間爲120-10=110。平均週轉時間爲（100+100+110）/3=103.33s

  5. 很明顯當工做可以隨時到達的狀況下，SJF可能會出現平均週轉時間較長的狀況

• 最短完成時間優先（STCF）

  1. 最短完成時間優先（Shortest Time-to-Completion First）：放寬假設3，即：調度程序能夠安排其它工做搶佔正在運行的工做佔用的CPU。

  2. 在SJF中添加了搶佔，每當新工做進入就緒狀態時，它就會肯定剩餘工做和新工做中，誰的完成時間最少，而後調度這個工做

  3. 在上述4的狀況下，STCF將搶佔A並先運行完B和C後，纔會繼續運行。則A的週轉時間爲120s，B的週轉時間爲10s，C的週轉時間爲20s，平均週轉時間爲(120+10+20)/3=50，顯著下降了SJF相同狀況下的平均週轉時間

• 增長考慮因素

  1. 當符合假設四、5成立時，即：知道任務長度，而且任務只使用CPU，根據當前的惟一衡量指標爲週轉時間時，STCF是一個很好的策略。可是，引入分時系統時，就出現了問題，由於此時須要任務和用戶進行交互，而週轉時間沒法衡量任務的交互性

  2. 響應時間（response time）：可以衡量任務的交互性，定義爲從任務到達系統到首次運行的時間
     

• 輪轉（RR）

  1. 輪轉（Round-Robin）：在一個時間片內運行一個工做，而後切換到運行隊列的下一個任務，而不是運行一個任務直到結束。它反覆執行，直到全部任務完成。

  2. 時間片長度必須時時鐘週期的倍數。若是不是，進行上下文切換的時候須要等待一段時間，此時CPU沒工做，就浪費了CPU資源

  3. 假設3個任務，A、B、C在系統中同時到達，而且它們都但願運行5s，SJF調度程序必須運行完當前任務才能運行下一個任務，而1s時間片的RR可以快速循環工做。RR平均響應時間爲：（0+1+2）/3=1（注：同時到達，到達時間爲0），SJF算法平均響應時間爲（0+5+10）/3=5
     

  4. 時間片長度對RR相當重要，越短，RR在響應時間上的表現越好，可是時間片不能設置得過短：忽然上下文切換會影響總體性能。由於上下文切換的成本不只僅來自保存和恢復少許寄存器的操做系統操做。程序在運行時，還會在CPU高速緩存、TLB、分支預測器和其餘片上的硬件中創建了大量的狀態。因此時間片長度須要慎重權衡，讓它足夠長，以便攤銷上下文切換成本，而又不會讓系統不及時響應

  5. 攤銷（amortize)：經過減小成本的頻度（即：執行較少的操做），系統的總成本就會下降。例如：若是時間片設置爲10ms，而且上下文切換時間爲1ms，大約會浪費10%的時間用於上下文切換。爲了攤銷這個成本，能夠把時間片長度增長到100ms，則只有不到1%的時間會用於上下文切換。

  6. 在3中，咱們只考慮了響應時間，沒考慮週轉時間，若是計算RR的週轉時間，A爲13，B爲14，C爲15，平均14。而SJF的週轉時間爲，A爲5，B爲10，C爲15，平均10.此時RR雖然響應時間較好，可是週轉時間較差。

  7. 到目前爲止。有兩類調度程序

     （1）SJF、STCF優化了週轉時間，可是響應時間——交互性很差

     （2）RR優化了響應時間，可是週轉時間很差

• 結合I/O

  1. 放寬假設4，即：工做會執行I/O，此時調度程序會面臨兩個問題

     （1）發起I/O請求作出決定，由於當前運行的任務在I/O期間不會使用CPU，它會被阻塞等待I/O完成。這時調度程序須要考慮是否等待該任務的執行仍是安排另外一項任務

     （2）I/O完成時作出決定。I/O完成時會產生中斷，操做系統運行並將發出I/O的進程從阻塞狀態移回到就緒狀態。此時調度程序將考慮是繼續執行該任務，仍是執行其餘任務

  2. 假設有兩項工做A、B，每項工做須要50ms的CPU時間。A每運行10ms，就會發出一次I/O請求，而B只是單純地使用CPU50ms.調度程序先運行A再運行B。假設構建STCF調度程序。能夠將A的每一個10ms的子工做看做是一項獨立的工做。因此任務運行時，先執行A10ms的子任務，完成後，會執行B，當I/O請求完成後，就會搶佔B並運行10ms，這樣就會充分利用系統。

  3. 當交互式做業（即：I/O請求較多）正在執行I/O時，其餘CPU密集型任務（即：I/O操做不多）將運行，從而更好的利用處理器

• 多級反饋隊列（MLFQ）

  1. 多級反饋隊列（Multi-level Feedback Queue，MLFQ）須要解決的問題

     （1）優化週轉時間

     （2）放寬假設5，即：不知道任務運行時間

     （3）下降響應時間，獲取更好的交互體驗

  2. 基本構成：有許多獨立的隊列，每一個隊列有不一樣的優先級（priority level）

  3. 基本規則：

     （1）規則1：若是A的優先級>B的優先級，運行A（不運行B）

     （2）規則2：若是A的優先級=B的優先級，輪轉運行A和B

  4. 如何改變優先級（1）？

     （1）系統須要執行的任務能夠分爲下列兩類

     ​ a. 運行時間很短、頻繁放棄CPU的交互性任務

     ​ b. 須要不少CPU時間、響應時間不是很重要的長時間計算密集型任務

     （2）優先級調整算法

     ​ a. 規則3：任務進入系統時，放在最高優先級（最上層隊列）

     ​ b. 規則4a：任務用完整個時間片後，下降優先級（移入下一個隊列）

     ​ c. 規則4b：若是工做再其時間片內主動釋放CPU，則優先級不變

     （3）實例1：單個長工做

     下圖展現了一個有三個隊列的調度程序。該工做首先進入最高優先級（Q2），執行10ms的時間片後，優先級-1，最終進入Q1，並一直到執行完畢

     （4）實例2：來了一個短工做

     有兩個工做：A時一個長時間運行的CPU密集任務，B是一個運行時間很短的交互型任務。假設A執行一段時間後B到達。下圖中A（用黑色表示）在最低優先隊列中（由（3）可知：長時間任務很長時間都會在最低隊列中），B（用灰色表示）在時間T=100時到達，並加入最高優先級隊列中。因爲它運行時間很短，通過兩個時間片，在被移入最低優先級隊列以前，B執行完畢。而後A繼續運行。

     （5）MLFQ算法的目標：若是不知道任務時短任務仍是長任務，那麼就在考試的時候假設它時短任務，並賦予最高優先級。若是確實是短任務，則會很快執行完畢。不然就會被慢慢移入低優先級隊列，而這個時候該任務也被認爲是長任務了。經過這種方式，MLFQ近似於SJF。

     （6）實例3：有I/O

     根據4b，交互型工做中有大量的I/O操做（好比等待用戶的鍵盤或鼠標輸入），它會在時間片用完以前放棄CPU，在這種狀況下，咱們會保持它的優先級不變

     假設交互型工做B（用灰色表示）每執行1ms便須要進行I/O操做，它與長時間運行的工做A（用黑色表示）競爭CPU。MLFQ算法保持B在最高優先級，由於B老是讓CPU。若是B是交互型工做，MLFQ就進一步實現了它的目標，讓交互型工做快速運行。

  5. 如今，MLFQ在長時間任務之間能夠公平地分享CPU，又能給短工做或交互型工做很好地響應時間。這樣就完美呢？其實還有問題

     a. 飢餓問題（starvation）問題。即：系統有許多交互型工做，就會不停地搶佔長時間任務地CPU，讓它們永遠沒法獲得CPU

     b. 愚弄調度程序（game the scheduler）。即：進程在時間片用完以前，調用一個I/O操做（好比訪問一個無關的文件），從而主動釋放CPU。如此即可以保持吃在高優先級，佔用更多的CPU時間

     c. 一個程序可能在不一樣時間表現不一樣。即：一個計算密集型的進程可能在某段時間表現爲一個交互型的進程

• 如何提升優先級（2)?

  1. 如何解決上述5中的問題？

     週期性地提高全部任務地優先級。最簡單的就是週期性的將全部任務放到最高優先級隊列中

     規則5：通過一段時間S，就將系統的任務從新加入到最高優先級隊列中。

  2. 新規則解決的問題

     （1）進程不會餓死——在最高優先級隊列中，它會以RR的方式，和其餘高優先級工做分享CPU，從而最終得到執行

     （2）若是一個CPU密集型工做變成了交互型，當它的優先級提高，調度程序會正確對待它

  3. 下邊有兩張圖，左邊沒有優先級提高，長時間任務在兩個短任務到達後被餓死。右邊的每隔50ms就有一次優先級提高（50ms只是舉例），所以至少保證了長任務的工做會有必定的進程，每過50ms就被提高到最高優先級，從而按期得到執行。

  4. 剩餘問題

     （1）S的值如何設置？若是S設置得過高，長任務會被餓死，若是過低，交互型工做得不到合適的CPU時間比例

     （2）如何阻止調度程序被愚弄？工做在時間片之內釋放CPU就保留它的優先級是存在問題的

• 選擇好的計時方式

  1. 更完善的CPU計時方式：調度程序應該記錄一個進程在某一層消耗的總時間，只要進程用完了本身的配額，就將它降到低一級的優先級隊列中。

  2. 重寫規則4a和4b

     規則4：一旦工做用完了其在某一層的時間配額（不管中間主動放棄了多少次的CPU），就下降其優先級（移入低一級隊列）

  3. 下圖對比了在規則4a、4b的策略下（左圖），以及在新的規則4（右圖）的策略下，一樣試圖愚弄調度程序的進程的表現。滅有規則4的保護下，進程能夠在每一個時間片結束前發起一次I/O操做，從而壟斷CPU時間，有了這樣的保護，不管進程的I/O行爲如何，都會慢慢下降優先級

• MLFQ調優以及其餘問題

  問題：

  （1）配置多少隊列

  （2）每一層隊列的時間片配置多大

  這些問題沒有顯而易見的答案，只有利用對工做負載的經驗以及後續對調優程序的調優，纔會取得使人滿意的平衡

  例如：高優先級隊列一般只有較短的時間片，使得交互型工做可以更快的切換。而低優先級隊列中更多的是CPU密集性工做，配置更長的時間片會更好

• MLFQ規則小結

  （1）規則1：若是A的優先級>B的優先級，運行A（不運行B）

  （2）規則2：若是A的優先級=B的優先級，輪轉運行A和B

  （3） 規則3：任務進入系統時，放在最高優先級（最上層隊列）

  （4）規則4：一旦工做用完了其在某一層的時間配額（不管中間主動放棄了多少次的CPU），就下降其優先級（移入低一級隊列）

  （5）規則5：通過一段時間S，就將系統的任務從新加入到最高優先級隊列中。