Linux內核——進程管理之CFS調度器（基於版本4.x）

《奔跑吧linux內核》3.2筆記，不足之處還望你們批評指正

建議閱讀博文http://www.javashuo.com/article/p-movdxjzv-gw.html理解linux cfs調度器

　　進程大體能夠分爲交互式進程，批處理進程和實時進程。對於不一樣的進程採用不一樣的調度策略，目前Linux內核中默認實現了4種調度策略，分別是deadline、realtime、CFS和idle，分別適用struct sched_class來定義調度類。

　　4種調度類經過next指針串聯在一塊兒，用戶空間程序可使用調度策略API函數（sched_setscheduler()）來設定用戶進程的調度策略。

問題一：請簡述對進程調度器的理解，早起Linux內核調度器（包括O(N)和O(1)）調度器是如何工做的？

　　調度器是按必定的方式對進程進行調度的一種機制，須要爲各個普通進程儘量公平地共享CPU時間。

　　O(N)調度器發佈與1992年，從就緒隊列中比較全部進程的優先級，而後選擇一個最高優先級的進程做爲下一個調度進程。每個進程有一個固定時間片，當進程時間片使用完以後，調度器會選擇下一個調度進程，當全部進程都運行一遍後再從新分配時間片。這個調度器選擇下一個調度進程前須要遍歷整個就緒隊列，花費O(N)時間。

　　O(1)調度器用於Linux2.6.23內核以前，它爲每一個CPU維護一組進程優先級隊列，每一個優先級一個隊列，這樣在選擇下一個進程時，只要查詢優先級隊列相應的位圖便可知道哪一個隊列中有就緒進程，查詢時間常數爲O(1)。

問題二：請簡述進程優先級、nice和權重之間的關係。

　　內核使用0~139的數值表示進程的優先級，數值越低優先級越高。優先級0~99給實時進程使用，100~139給普通進程使用。在用戶空間由一個傳統的變量nice值映射到普通進程的優先級(100~139)。

　　nice值從-20~19，進程默認的nice值爲0。這能夠理解爲40個等級，nice值越高，則優先級越低，反之亦然。（nice每變化1，則相應的進程得到CPU的時間就改變10%）。

　　權重信息即爲調度實體的權重，爲了計算方便，內核約定nice值爲0的權重值爲1024，其餘的nice值對應相應的權重值能夠經過查表的方式來獲取，表即爲prio_to_weight。

問題三：請簡述CFS調度器是如何工做的。

　　CFS調度器拋棄之前固定時間片和固定調度週期的算法，採用進程權重值的比重來量化和計算實際運行時間。引入虛擬時鐘的概念，每一個進程的虛擬時間是實際運行時間相對nice值爲0的權重的比例值。進程按照各自不一樣的速率比在物理時鐘節拍內前進。nice值小的進程，優先級高且權重大，其虛擬時鐘比真實時鐘跑得慢，可是能夠得到比較多的運行時間；反之，nice值大的進程，優先級低，權重也低，其虛擬時鐘比真實時鐘跑得快，得到比較少的運行時間。CFS調度器老是選擇虛擬時鐘跑得慢的進程，相似一個多級變速箱，nice值爲0的進程是基準齒輪，其餘各個進程在不一樣變速比下相互追趕，從而達到公正公平。

問題四：CFS調度器中的vruntime是如何計算的？

　　vruntime=(delta_exec*nice_0_weight)/weight。其中，delta_exec爲實際運行時間，nice_0_weight爲nice爲0的權重值，weight表示該進程的權重值。在update_curr()函數中，完成了該值的計算，此時，爲了計算高效，將計算方式變成了乘法和移位vruntime=(delta_exec*nice_0_weight*inv_weight)>>shift，其中inv_weight=2^32/weight，是預先計算好存放在prio_to_wmult中的。

問題五：vruntime是什麼時候更新的？

　　建立新進程，加入就緒隊列，調度tick等都會更新當前vruntime值。

問題六：CFS調度器中的min_vruntime有什麼做用？

　　min_vruntime在CFS就緒隊列數據結構中，單步遞增，用於跟蹤該就緒隊列紅黑樹中最小的vruntime。

問題七：CFS調度器對新建立的進程和剛喚醒的進程有何關照？

　　對於睡眠進程，其vruntime在睡眠期間不增加，在喚醒後若是還用原來的vruntime值，會進行報復性滿載運行，因此要修正vruntime，具體在enqueue_entity()函數中，計算公式爲vruntime+=min_vruntime，vruntime=MAX(vruntime, min_vruntime-sysctl_sched_lantency/2)。

　　對於新建立的進程，須要加上一個調度週期的虛擬是時間(sched_vslice())。首先在task_fork_fair()函數中，place_entity()增長了調度週期的虛擬時間，至關於懲罰，se->vruntime=sched_vslice()。接着新進程在添加到就緒隊列時，wake_up_new_task()->activate_task()->enqueue_entity()函數裏，se->vruntime+=cfs_rq->min_vruntime。

問題八：如何計算普通進程的平均負載load_avg_contrib？runnable_avg_sum和runnable_avg_period分別表示了什麼含義？

　　load_avg_contrib=runnable_avg_sum*weight/runnable_avg_period。

　　runnable_avg_sum爲調度實體的可運行狀態下總衰減累加時間。

　　runnable_avg_period記錄的是上一次更新時的總週期數（一個週期是1024us），即調度實體在調度器中的總衰減累加時間。

　　runnable_avg_sum越接近runnable_avg_period，則平均負載越大，表示該調度實體一直在佔用CPU。

問題九：內核代碼中定義了若干個表，請分別說出它們的含義，好比prio_to_weight、prio_to_wmult、runnable_avg_yN_inv、runnable_avg_yN_sum。

　　prio_to_weight表記錄的是nice值對應的權重值。

　　prio_to_wmult表記錄的是nice值對應的權重值倒轉後的值inv_weight=2^32/weight。

　　runnable_avg_yN_inv表是爲了不CPU作浮點計算，提早計算了公式2^32*實際衰減因子（第32ms約爲0.5）的值，有32個下標，對應過去0~32ms的負載貢獻的衰減因子。

　　runnable_avg_yN_sum表爲1024*（y+y^2+…+y^n），y爲實際衰減因子，n取1~32。（實際衰減因子下圖所示）

圖 實際衰減因子

問題十：若是一個普通進程在就緒隊列裏等待了很長時間才被調度，那麼它的平均負載該如何計算？

 　　一個進程等待很長時間以後（過了不少個period），原來的runnable_avg_sum和runable_ave_period值衰減後可能變成0，至關於以前的統計值被清0。