Linux內(nèi)核模塊

ip內(nèi)核模塊有3 種不同形式:軟ip 核(soft ip core)、固ip 核(firm ip core)和硬ip 核(hard ip core)。 1.軟ip 核 軟ip 核主要是基于ip 模塊功能的描述。它在抽象的較高層次上對ip 的功能進(jìn)行描述，并且已經(jīng)過行為級設(shè)計(jì)優(yōu)化和功能驗(yàn)證。它通常以hdl 文檔的形式提交給用戶，文檔中一般包括邏輯描述、網(wǎng)表，以及一些可以用于測試，但不能物理實(shí)現(xiàn)的文件。使用軟ip，用戶可以綜合出正確的門電路級網(wǎng)表，進(jìn)行后續(xù)結(jié)構(gòu)設(shè)計(jì)，并借助eda 綜合工具與其他外部邏輯電路結(jié)合成一體，設(shè)計(jì)出需要的器件。雖然，軟ip 的靈活性大，可移植性好，但同硬ip 相比，因?yàn)樗缓腥魏尉唧w的物理信息，所以如果后續(xù)設(shè)計(jì)不當(dāng)，很可能導(dǎo)致設(shè)計(jì)失敗。另外，后續(xù)的布局布線工作也將花費(fèi)大量的時間。 2.硬ip 核硬ip 核主要是基于ip 模塊物理結(jié)構(gòu)的描述。它提供給用戶的形式是電路物理結(jié)構(gòu)掩模版圖和全套工藝文件，是可以拿來就用的全套技術(shù)。其優(yōu)點(diǎn)為，完成了全部的前端和后端設(shè)計(jì)，已有固定的電路布局局和具體工藝，可以確保性能，并縮短soc 的設(shè)計(jì)時間。但因?yàn)槠潆娐凡季趾凸に囀枪潭ǖ?，同時也導(dǎo)致了靈活性較差，難以移植到不同的加工工藝。 3.固ip 核 固ip 核主要是基于ip 模塊結(jié)構(gòu)的描述，可以理解為介于硬ip 和軟ip 之間的ip 核。固ip 一般以門電路級網(wǎng)表和對應(yīng)具體工藝網(wǎng)表的混合形式提交用戶使用。以便用戶根據(jù)需要進(jìn)行修改，使它適合某種可實(shí)現(xiàn)的工藝流程。近年來電子產(chǎn)品的更新?lián)Q代周期不斷縮短，而系統(tǒng)芯片的復(fù)雜程度卻在增長，為了緩和這一矛盾，soc 設(shè)計(jì)普遍采用基于ip 模塊的設(shè)計(jì)方法。因?yàn)閕p模塊是預(yù)先設(shè)計(jì)好的，并通過了驗(yàn)證，設(shè)計(jì)者可以把注意力集中于整個系統(tǒng)，而不必考慮各個模塊的正確性和性能，這除了能縮短soc 芯片設(shè)計(jì)的時間外，還能降低設(shè)計(jì)和制造成本，提高可靠性。ip 重用技術(shù)使芯片設(shè)計(jì)從以硬件為中心，逐漸轉(zhuǎn)向以軟件為中心，從門級的設(shè)計(jì)，轉(zhuǎn)向ip 模塊和ip 接口級的設(shè)計(jì)。

linux調(diào)度器(BFS )是一款專門為 Linux 桌面環(huán)境所設(shè)計(jì)的內(nèi)核調(diào)度器，它基于 Staircase Deadline和 EEVDF 算法，支持 Linux 2.6.31之后的內(nèi)核。它提供了前所未有的流暢桌面性能，不僅得到了用戶的認(rèn)可，也為一些商業(yè)系統(tǒng)所采用。

BFS vs CFS，設(shè)計(jì)上的不同 白天 Con Kolivas 在醫(yī)院里當(dāng)麻醉師，為人們解除痛苦，業(yè)余的時候借 Linux 解除自己的痛苦。額，Kolivas 學(xué)習(xí) Linux 并不是為了解決痛苦，我臆測而已。但據(jù) Kolivas 自述，他接觸 Linux 內(nèi)核時連 C 語言也沒有學(xué)習(xí)過。。。這個事實(shí)證明，語言只是一項(xiàng)工具，對問題本質(zhì)的深入理解才是寫程序的關(guān)鍵?？赡苓€有執(zhí)著，CFS 和 RSDL 之爭導(dǎo)致 Kolivas 離開 Linux 社區(qū)，此去經(jīng)年，當(dāng) Kolivas 再次開始看內(nèi)核代碼的時候，他立即發(fā)現(xiàn) CFS 存在以下幾個設(shè)計(jì)上的問題:

CFS 的目標(biāo)是支持從桌面到高端服務(wù)器的所有應(yīng)用場景，這種大而全的設(shè)計(jì)思路導(dǎo)致其必須做一些實(shí)現(xiàn)上的折中，此外，那些只有在高端機(jī)器中才需要的特性將引入不必要的復(fù)雜代碼。

其次，為了維護(hù)多 CPU 上的公平性，CFS 采用了負(fù)載平衡機(jī)制，Kolivas 認(rèn)為，這些復(fù)雜代碼抵消了 per cpu queue 曾帶來的好處。

最后，主流內(nèi)核的 CFS 還是對睡眠進(jìn)程存在一些偏好，這意味著"不公平"。

在現(xiàn)實(shí)中，調(diào)度算法類似一個處境尷尬的主婦，滿足孩子對晚餐的要求便有可能傷害到老人的食欲。Linux 內(nèi)核一直試圖做出一道讓全家老少都喜歡的菜，在這方面，CFS 已經(jīng)做的很好。但一道能被所有人接受的菜，或許就意味著稍許平淡。而 BFS 只打算滿足一種口味，以便將這種口味發(fā)展到極限。

根據(jù) Linux Magazine的說法，Con Kolivas是看到了下面這則來自 xkcd 的漫畫而開始思考 BFS 的。

事情源于一些 Linux 用戶，他們發(fā)現(xiàn) Linux 雖然號稱能夠充分發(fā)揮 4096 顆 CPU 系統(tǒng)的計(jì)算能力，但在普通的 laptop 上卻無法流暢地播放 Youtube 視頻。

這讓人們開始思考，對于 Desktop 環(huán)境來講，CFS 哪些復(fù)雜的特性究竟是否還有意義?人們是否有必要在自己的個人電腦中使用一個支持 4096 個 CPU 的調(diào)度器?

BFS 正是對這種質(zhì)疑的自然反應(yīng)。它不打算支持 4096 個 CPU 的龐然大物，BFS 的目標(biāo)是普通人使用的桌面電腦。此外，BFS 還刪除了那些只有在服務(wù)器上才需要的特性。比如，BFS 拋棄了 CFS 的組調(diào)度特性，類似 CGROUP 這樣的特性對于普通的桌面用戶是多余的技術(shù)。

這很容易理解:在只有一個 CPU 的系統(tǒng)中，誰還會設(shè)計(jì)多個 CGroup，哪里還能用到 NUMA domain等概念呢?

此外 BFS 使用單一的 run queue，不再需要復(fù)雜的負(fù)載均衡機(jī)制。由于不再有 CGROUP 概念，也不再需要 Group 間的負(fù)載均衡。

這些簡單的裁剪使得 BFS 的代碼極大地簡化，簡化的代碼意味著執(zhí)行一次調(diào)度所需要的指令數(shù)減少了，相應(yīng)的 footprint 自然也減少了。

當(dāng)然簡化代碼只是一個顯而易見的方面，更重要的是，這種理念的不同會對最終的調(diào)度器實(shí)現(xiàn)產(chǎn)生更加深遠(yuǎn)的影響，這實(shí)在是難以盡述。

多隊(duì)列 vs 單一隊(duì)列

?在 Linux 內(nèi)核進(jìn)入 2.6 時，調(diào)度器采用 per cpu run queue 從而克服了單一 run queue 的局限。在多 CPU 系統(tǒng)中，單一 run queue 意味著 run queue 成為了系統(tǒng)的瓶頸，因?yàn)樵谕粫r刻，一個 CPU 訪問 run queue 時，其他的 CPU 即使空閑也必須等待。當(dāng)使用 per CPU 的 run queue 之后，每個 CPU 不必再使用大鎖，從而能夠并行地處理調(diào)度。

但很多事情都不像第一眼看上去那樣簡單。

Kolivas 發(fā)現(xiàn)，采用 per cpu run queue 所帶來的好處會被追求公平性的 load balance 代碼所抵消。在目前的 CFS 調(diào)度器中，每顆 CPU 只維護(hù)本地 run queue 中所有進(jìn)程的公平性，為了實(shí)現(xiàn)跨 CPU 的調(diào)度公平性，CFS 必須定時進(jìn)行 load balance，將一些進(jìn)程從繁忙的 CPU 的 run queue 中移到其他空閑的 run queue 中。

這個 load balance 的過程需要獲得其他 run queue 的鎖，這種操作降低了多運(yùn)行隊(duì)列帶來的并行性。

并且在復(fù)雜情況下，這種因 load balance 而引入的 footprint 將非?？捎^。

當(dāng)然，load balance 引入的加鎖操作依然比全局鎖的代價要低，這種代價差異隨著 CPU 個數(shù)的增加而更加顯著。但請您注意，BFS 并不打算為那些擁有 1024 個 CPU 的系統(tǒng)工作，假若系統(tǒng)中的 CPU 個數(shù)有限時，多 run queue 的優(yōu)勢便不明顯了。

而 BFS 采用單一隊(duì)列之后，每一個需要調(diào)度的新進(jìn)程都可以在全局范圍內(nèi)查找最合適的 CPU，而無需 CFS 那樣等待 load balance 代碼來決定，這減少了多 CPU 之間裁決的延遲，最終的結(jié)果是更小的調(diào)度延遲。

向前看還是向后看?

多年來 Kolivas 一直關(guān)注著 Linux 在 desktop 上的表現(xiàn)。對于 desktop 的用戶，最注重的不是系統(tǒng)的吞吐量，而是交互性程序的流暢體驗(yàn)。從 SD 開始，Kolivas 就告訴內(nèi)核黑客們，完全公平能夠從根本上保證交互性。他始終堅(jiān)持一個基本觀點(diǎn):調(diào)度器應(yīng)該 forward look only。決不要去考慮一個進(jìn)程的過去。

CFS 卻偏偏要考慮進(jìn)程的過去。2.6.23 的時候，CFS 記錄并使用 sleep time。之后不久，在 2.6.24 發(fā)布的時候，CFS 合并了"Real Fair Scheduler"，刪除了 sleep time。因此在 2.6.24 之后的內(nèi)核中，CFS 終于也不再考慮進(jìn)程過去的睡眠時間。

但 CFS 還是保留了 sleeper fairness 的思想，當(dāng)進(jìn)程 wakeup 的時候，在 place_entity() 函數(shù)中，CFS 將對 sleeper 進(jìn)行獎勵，以便其能盡快得到 CPU。這個策略是非常微妙的，我們在 2.1 節(jié)中詳細(xì)介紹了 sleeper fairness 的演進(jìn)過程。假如您花些時間回頭再看看，就會發(fā)現(xiàn) sleeper fairness 曾造成怎樣嚴(yán)重的延遲問題。雖然 Ingo 自稱 Gentle fairness 解決了延遲問題，但從代碼上看，Gentle Fairness 只是對 sleeper 的獎勵減半而已。因此我們可以說，CFS 依然對 Sleeper 進(jìn)程進(jìn)行獎勵，這代表著一種偏好，一種"不公平"。而這，正是 BFS 所反對的。

BFS 中，當(dāng)一個進(jìn)程 wakeup 時，調(diào)度器將根據(jù)進(jìn)程的 deadline 來進(jìn)行選擇(關(guān)于 deadline 本文將在第 4 章中詳細(xì)描述)，其結(jié)果是，更早睡眠的進(jìn)程能更快地得到調(diào)度;CFS 的 sleeper fairness 則意味著要根據(jù) wakeup 的時間來選擇下一個被調(diào)度的進(jìn)程，更早 wakeup 的進(jìn)程會更快得到調(diào)度。

這種不同究竟會對桌面應(yīng)用造成何種影響尚沒有理論依據(jù)可以參考。但我個人認(rèn)為，BFS 的策略更加合理。

您現(xiàn)在可能已經(jīng)讀得有些煩躁了 ( 這些英文加中文的說些啥啊 )，所以我還是盡快介紹一下 BFS 的實(shí)現(xiàn)細(xì)節(jié)吧。然后或許您會理解我，有些詞還是不翻譯更好。