linux核心調度演算法（1）--快速找到最高優先順序進程

標籤：高清視頻   指標   linux核心   一個   size   核心源碼   包括   reduce   搶佔式   

為什麼要瞭解核心的調度策略呢？呵呵，因為它值得我們學習，不算是廢話吧。核心發送器很先進很強大，管理你的LINUX上跑的大量的亂七八糟的進程，同時還保持著對使用者操作的高靈敏響應，如果可能，為什麼不把這種思想放到自己的應用程式裡呢？或者，有沒有可能更好的實現自己的應用，使得作業系統能夠以自己的意志來分配資源給自己的進程？

帶著這兩個問題來看看KERNEL。首先回顧上我們開發應用程式，基本上就兩種類型，1、IO消耗型：比如hadoop上的trunk服務，很明顯它的消耗主要在IO上，包括網路IO磁碟IO等等。2、CPU消耗型，比如mapreduce或者其他的需要對大量資料進行計算處理的組件，就象對高清視頻壓縮成適合手機觀看解析度的進程，他們的消耗主要在CPU上。當兩類進程都在一台SERVER上運行時，作業系統會如何調度它們呢？現在的伺服器都是SMP多核的，那麼一個進程在多CPU時會來回切換嗎？如果我有一個程式，既有IO消耗又有CPU消耗，怎麼讓多核更好的調度我的程式呢？


又多了幾個問題。來看看核心發送器吧，我們先從它的優先隊列談起吧。發送器代碼就在核心源碼的kernel/sched.c的schedule函數中。
首先看下面的優先順序隊列，每一個runqueue都有。runqueue是什嗎？下面會詳細說下，現在大家可以理解為，核心為每一顆CPU分配了一個runqueue，用於維護這顆CPU可以啟動並執行進程。runqueue裡，有幾個成員是prio_array類型，這個東東就是優先隊列，先看看它的定義：

看看BITMAP_SIZE是怎麼算出來的：#define BITMAP_SIZE ((((MAX_PRIO+1+7)/8)+sizeof(long)-1)/sizeof(long))
那麼，LINUX預設配置（如果你用預設選項編譯核心的話）MAX_PRIO是140，就是說一共核心對進程一共定義了140種優先順序。等待某個CPU來處理的進程中，可能包含許多種優先順序的進程，但，LINUX是個搶佔式調度演算法的作業系統，就是說，需要調度時一定是找到最高優先順序的進程執行。上面的BITMAP_SIZE值根據MAX_PRIO算出來為5，那麼bitmap實際是32*5=160位，這樣就包含了MAX_PRIO的140位。優先順序隊列是怎麼使用的？看2649行代碼：idx=sched_find_first_bit(array->bitmap);這個方法就用來快速的找到優先順序最高的隊列。看看它的實現可以方便我們理解這個優先順序位的設計：

那麼__ffs是幹什麼的？

sched_find_first_bit傳回值就是最高優先順序所在隊列的序號，與queue是對應使用的哈，queue=array->queue + idx;這樣就取到了要處理的進程隊列。這個設計在尋找優先順序時是非常快的，非常值得我們學習。


好，優先順序隊列搞明白了，現在來看看runqueue，每個runqueue包含三個優先順序隊列。

LINUX是一個時間多工系統，就是說，通過把CPU執行時間分成許多片，再分配給進程們使用，造成即使單CPU系統，也貌似允許多個任務在同時執行。那麼，時間片大小假設為100ms，過短過長，過長了有些不靈敏，過短了，連切換進程時可能都要消耗幾毫秒的時間。分給100個進程執行，在所有進程都用完自己的時間片後，需要重新給所有的進程重新分配時間片，怎麼分配呢？for迴圈遍曆所有的run狀態進程，重設時間片？這個效能無法容忍！太慢了，跟當前系統進程數相關。那麼2.6核心怎麼做的呢？它用了上面提到的兩個優先順序隊列active和expired，顧名思義，active是還有時間片的進程隊列，而expired是時間片耗盡必須重新分配時間片的進程隊列。


這麼設計的好處就是不用再迴圈一遍所有進程重設時間片了，看看調度函數是怎麼玩的：

當所有運行進程的時間片都用完時，就把active和expired隊列互換指標，沒有遍曆哦，而時間片耗盡的進程在出acitve隊列入expired隊列時，已經單獨的重新分配好新時間片了。


再看一下schedule(void)調度函數，當某個進程休眠或者被搶佔時，系統就開始調試schedule(void)決定接下來運行哪個進程。上面說過的東東都在這個函數裡有體現哈。

當然，在我們程式中，也可以通過執行以下系統調用來改變自己進程的優先順序。nice系統調用可以改變某個進程的基本優先順序，setpriority可以改變一組進程的優先順序。

linux核心調度演算法（1）--快速找到最高優先順序進程