內核為了處理來自IO層的請求，需要進行相應的優化，因為當請求很多時，且請求的塊又都幾種在一塊，那麼如果按照順序處理這些請求無疑是很大的時間開銷，所以，我們需要尋求方法來處理這種情況（當然，不只是這一種情況），這篇文章介紹的就是Linux中經典的IO調度程序--Linus電梯，這個是以Linux的發明者Linus自己的名字命名的。在2.4版的內核中，Linus電梯是默認的IO調度程序。雖然在後來的2.6版內核中它被另外兩個調度程序所取代了，但是由於這個調度程序比後來的調度程序簡單，而且它們執行的許多功能都相似，所以，它可以作為一個優秀的入門介紹程序。
首先，講解下為什麼這個調度程序被稱作是電梯調度
大家都知道，我們在讀磁盤上的數據時，首先肯定是磁頭進行尋址，找到數據存儲的位置（扇區）。而這個調度算法正是認為按著磁頭方向移動的順序調度請求是比較好的情況，當到達磁盤的末尾時，磁頭再轉換另一個方向移動到另一端，就像是生活中的電梯執行的方式，如下圖所示：
Linus電梯能執行合並於排序預處理。當有新的請求加入隊列時，它首先會檢查其他每一個掛起的請求是否可以和新的請求合並。Linus電梯IO調度程序可以執行向前和向後合並，合並類型描述的是請求向前面還是向後面，這一點和已有請求連接。如果新的請求正好連在一個現存的請求前，那麼就是向前合並；相反，如果一個請求連接在一個現存的請求之後，那麼就是向後合並。鑒於文件的分布特點和IO操作執行方式具有典型性，所以向前合並要比向後合並少得多，但是Linus電梯還是會對兩種合並類型都進行檢查。
如果合並嘗試失敗，那麼就需要尋找可能的插入點。如果找到，新的請求將被插入到該點；如果沒有合適的位置，那麼新的請求就被加入到隊列的末尾。
總而言之，當一個請求加入到隊列中時，有可能發生四種操作，它們依次是：
1> 如果隊列中已經存在一個相鄰磁盤扇區操作的請求，那麼新的請求將會和這個已經存在的請求進行合並
2> 如果隊列中存在一個駐留時間過長的請求，那麼新的請求將被插入到隊列尾部，已防止其他舊的請求存在饑餓現象
3> 如果隊列中以扇區方法為序存在合適的插入位置，那麼新的請求將被插入到該位置，保證隊列中的請求是以被訪問磁盤物理位置為序進行排列的
4> 如果隊列中不存在合適的請求插入位置，請求將被插入到隊列尾部
