linux調度器（二）——CFS模型

本系列文章閱讀的core是：2.6.32-220
這裡使用“模型”而不是“演算法”是因為這東西實在不好用演算法描述（但是它卻運行得很好，包括效能）。
         核心思想： 把CPU總時間按運行隊列的所有se的權重分配給每個se。每個se使用cpu的順序由它們已使用的cpu虛擬時間（vruntime）決定的，已使用的虛擬時間越少，它在運行隊列的位置越靠左，那麼它再次被調度執行的機率也就越高。每個se每次佔用cpu後能夠執行的時間（ideal_runtime）也由它們的權重決定，並且保證在某個時間周期（__sched_period）內運行隊列裡的所有se都能夠至少被調度執行一次。並且為了保證新進程能夠獲得合理的vruntime（不至於一開始太小導致長期佔用cpu，以及不同組之間的遷移的標準化），在每個cfs_rq上維護一個min_vruntime，所有的se
vruntime的調整按它自己的cfs_rq的min_vruntime為基準。
從上面的思想中，我們可以得到下面幾個關係：
vruntime增長速率決定了進程被調度的次數，而這個增率又是由進程的權重決定的，權重越大（優先順序越高，並且系統設定NICE_0_LOAD的vrumtime增率等待實際物理時間的增率），增率越慢；
保證每個進程被在一個周期內被調度至少一次的周期是由就緒隊列的進程個數決定的（以及sched_latency_ns共同決定，見後面的解釋）；
每個進程每次佔用cpu能夠執行的時間是由上面的周期、它本身的權重及該運行隊列總共的權重共同決定的，這個時間並不是代表進程獲得cpu後就一定能夠執行這麼多時間，這個只是它的上限，當有其它的更低vruntime的進程進入隊列的話，該進程就可以被搶佔，那麼它執行的時間就會少於這個ideal_runtime，但是由於它執行的時間少了點，所以它的vruntime步長也就變小了，所以會被放在紅/黑樹狀結構的靠左的位置。
    假設我們有A,B,C三個進程，它們的權重分別是1,2,3（1的vruntime增率與實質物理時間一致），並且假設運行周期為18ms（這樣每個進程的ideal_runtime分別為3ms,6ms,9ms，這裡直接使用常量是因為對於真實的系統它也是在當運行隊列的進程數超過一定數的時候才按正比來計算，當小於這個值的時候使用的就是一個常量），它們進入就緒隊列的順序就是A,B,C，為了便於理解，我們再假設它們進入時的vruntime都為0（其實這個由min_vruntime決定的，而min_vrumtime又由當前運行進程及當前隊列最小的vrumtime共同決定，在每次update_curr的時候都會進行更新），這樣A開始執行，假設A執行了2ms，那麼此時它的vruntime也等於2，如果現在B進來，那麼B的vruntime小於A，所以B搶佔了A，當B也執行了2ms，那麼它的vruntime等於1，這時C進來了，所以它也搶佔了B（B被重新放到就緒隊列裡，不過因為它的vruntime為1，所以它被放在A的左邊（之前）），此時C按調度周期它最長可以執行9ms，但是當它運行了>3ms後，它的vruntime>1，然後此時B進程就會搶佔C，依此類推。
         是的，如果真的如上面那樣執行的話，那麼系統的大多數時間將用在環境切換。顯然當C運動了3ms之後，它可以接著運行直到它把它的周期9ms運行完再切換，因為系統已經保證了在18ms內每個進程都被調度一次，那麼以至於多次切換後總共運行9ms，還不好一次讓它運行完，即CFS保證的是周期內的公平，微觀上不公平，不過也只有不公平，才會導致往公平的方向發展。在核心的實現上也是這樣的，只有當進程運行完它的周期才一定會被搶佔，否則還要判斷它的執行時間，如果小於系統預設的最小設定值，也不會被搶佔；在這種情況下（已耗用時間小於它的ideal_runtime）唯一允許搶佔的條件是：最左邊等待的vruntime（與當前進程的vruntime差值）大於當前進程的ideal_runtime（不知道為什麼是這樣一個條件：虛擬時間與物理時間的一個比較？？？這個過程在check_preempt_tick）。上面只是一個最基本的模型，它沒有考慮到進程被建立時的vruntime初始化，進程被暫停，喚醒……下面我們就來詳細看一下這些相應的過程。

參考文獻：

http://blog.csdn.net/janneoevans/article/details/8125106