現(xiàn)在回讀linux的調(diào)度器，O(1)調(diào)度器簡直就是一個過渡，2.4之前的O(n)調(diào)度器曾經(jīng)和cfs調(diào)度器是多么的接近啊！我們不應(yīng)該只把眼光注意在O(X)的括號內(nèi)，要知道這個括號內(nèi)的數(shù)字并不能說明這個調(diào)度器的優(yōu)劣，它僅僅是調(diào)度行為中的一環(huán)而已，是一個理想化的基本原則，正如80/20原則所言，真正為了修復(fù)這個理想情況中所有的不理想因素所花費的時間和空間要大得多，所以cfs調(diào)度器便拋棄了以前的命名法，難道它還能比O(1)命名法括號內(nèi)的數(shù)字更小嗎？顯然不能！

O(n)調(diào)度器下，只有運行隊列中再沒有進程的時候才會重新計算所有已經(jīng)被剝奪運行進程的時間片，睡眠中的進程并沒有得到特別的照顧，因為它們在還沒有耗盡時間片的時候就被剝奪了運行機會，因此其時間片可以被累加，這樣的話，一旦運行隊列中沒有進程了，實際上還有一些進程在睡眠，比如IO進程，比如交互進程。這個調(diào)度器和cfs調(diào)度器是多么得相似，只是缺少了：1.pick-next的高效算法；2.多處理器獨立隊列；...要知道算法的效率直接來源于數(shù)據(jù)結(jié)構(gòu)而不是思想，另外向多處理器的擴展本身就是一個擴展，也不能否定調(diào)度器的設(shè)計思想。很多人都對O(1)調(diào)度器情有獨鐘，拋開宣傳因素不講，其本身也算是帶來了兩三年的高效率，然而我個人在接觸了cfs調(diào)度器之后卻總是對O(1)調(diào)度器不甚看好，看看其設(shè)計是多么的復(fù)雜吧，有多少行代碼浪費在計算動態(tài)優(yōu)先級上，而計算動態(tài)優(yōu)先級本身就要涉及到睡眠時間，一個運行隊列分裂為兩個數(shù)組本身僅僅對于pick-next算法有利，為了這點微薄的利益，再看看饑餓避免算法吧...暴露在proc文件系統(tǒng)中的眾多調(diào)度器微調(diào)開關(guān)真的迷惑了很多年輕的程序員，當然也包括我自己。到頭來發(fā)現(xiàn)，真的不需要這么多的開關(guān)，cfs調(diào)度器實際上就是在O(n)調(diào)度器上進行了兩點修改，一個是將數(shù)組變成了紅黑樹，另一個就是支持了每cpu一棵樹，分級調(diào)度暫且不考慮。如果說cfs是一個去偽存真的調(diào)度器的話，它更多的是去除了O(1)的偽而保留了O(1)的真諦！雖然O(1)調(diào)度器和cfs調(diào)度器的設(shè)計者是一個人，我寧愿相信他在O(1)中繞了一大圈后回歸了原點。如果說O(n)調(diào)度器的時間大多浪費在pick-next，那么O(1)調(diào)度器確實可以迷惑很多人，因為調(diào)度器的命名法，很多人都以為調(diào)度器的工作就是pick-next。

去了華為面試，面試官看了我的簡歷，以調(diào)度器為題目企圖難為一個叫趙亞的大專生，茲以上文駁斥，遂無言，歸，不語！

轉(zhuǎn)載于:https://blog.51cto.com/dog250/1274132

總結(jié)

以上是生活随笔為你收集整理的调度器的精髓--优先级下兼顾公平的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。