在科技行業(yè)，創(chuàng)新這個(gè)詞幾乎和革命一樣到處泛濫，所以很難將那些夸張的東西與真正令人振奮的東西區(qū)分開來。Linux 內(nèi)核被稱為創(chuàng)新，但它又被稱為現(xiàn)代計(jì)算中最大的奇跡，一個(gè)微觀世界中的龐然大物。

撇開營銷和模式不談，Linux 可以說是開源世界中最受歡迎的內(nèi)核，它在近 30 年的生命時(shí)光當(dāng)中引入了一些真正的規(guī)則改變者。

Cgroups（2.6.24）

早在 2007 年，Paul Menage 和 Rohit Seth 就在內(nèi)核中添加了深?yuàn)W的控制組（cgroups）功能（cgroups 的當(dāng)前實(shí)現(xiàn)是由 Tejun Heo 重寫的）。這種新技術(shù)最初被用作一種方法，從本質(zhì)上來說，是為了確保一組特定任務(wù)的服務(wù)質(zhì)量。

例如，你可以為與你的 WEB 服務(wù)相關(guān)聯(lián)的所有任務(wù)創(chuàng)建一個(gè)控制組定義（cgroup），為例行備份創(chuàng)建另一個(gè) cgroup ，再為一般操作系統(tǒng)需求創(chuàng)建另一個(gè) cgroup。然后，你可以控制每個(gè)組的資源百分比，這樣你的操作系統(tǒng)和 WEB 服務(wù)就可以獲得大部分系統(tǒng)資源，而你的備份進(jìn)程可以訪問剩余的資源。

然而，cgroups 如今變得這么著名是因其作為驅(qū)動(dòng)云技術(shù)的角色：容器。事實(shí)上，cgroups 最初被命名為進(jìn)程容器。當(dāng)它們被 LXC、CoreOS 和 Docker 等項(xiàng)目采用時(shí)，這并不奇怪。

就像閘門打開后一樣，“容器” 一詞就像成為了 Linux 的同義詞一樣，微服務(wù)風(fēng)格的基于云的“應(yīng)用”概念很快成為了規(guī)范。如今，已經(jīng)很難擺脫 cgroups 了，它們是如此普遍。每一個(gè)大規(guī)模的基礎(chǔ)設(shè)施（如果你運(yùn)行 Linux 的話，可能還有你的筆記本電腦）都以一種合理的方式使用了 cgroups，這使得你的計(jì)算體驗(yàn)比以往任何時(shí)候都更加易于管理和靈活。

例如，你可能已經(jīng)在電腦上安裝了 Flathub 或 Flatpak，或者你已經(jīng)在工作中使用 Kubernetes和/或 OpenShift。不管怎樣，如果“容器”這個(gè)術(shù)語對(duì)你來說仍然模糊不清，則可以 通過 Linux 容器從背后獲得對(duì)容器的實(shí)際理解。

LKMM（4.17）

2018 年，Jade Alglave、Alan Stern、Andrea Parri、Luc Maranget、Paul McKenney 以及其他幾個(gè)人的辛勤工作的成果被合并到主線 Linux 內(nèi)核中，以提供正式的內(nèi)存模型。Linux 內(nèi)核內(nèi)存［一致性］模型（LKMM）子系統(tǒng)是一套描述 Linux 內(nèi)存一致性模型的工具，同時(shí)也產(chǎn)生用于測(cè)試的用例（特別命名為 klitmus）。

隨著系統(tǒng)在物理設(shè)計(jì)上變得越來越復(fù)雜（增加了更多的中央處理器內(nèi)核，高速緩存和內(nèi)存增長，等等），它們就越難知道哪個(gè)中央處理器需要哪個(gè)地址空間，以及何時(shí)需要。例如，如果 CPU0 需要將數(shù)據(jù)寫入內(nèi)存中的共享變量，并且 CPU1 需要讀取該值，那么 CPU0 必須在 CPU1 嘗試讀取之前寫入。類似地，如果值是以一種順序方式寫入內(nèi)存的，那么期望它們也以同樣的順序被讀取，而不管哪個(gè)或哪些 CPU 正在讀取。

即使在單個(gè)處理器上，內(nèi)存管理也需要特定的任務(wù)順序。像 x = y 這樣的簡(jiǎn)單操作需要處理器從內(nèi)存中加載 y 的值，然后將該值存儲(chǔ)在 x 中。在處理器從內(nèi)存中讀取值之前，是不能將存儲(chǔ)在 y 中的值放入 x 變量的。此外還有地址依賴：x［n］ = 6 要求在處理器能夠存儲(chǔ)值 6 之前加載 n。

LKMM 可以幫助識(shí)別和跟蹤代碼中的這些內(nèi)存模式。它部分是通過一個(gè)名為 herd 的工具來實(shí)現(xiàn)的，該工具（以邏輯公式的形式）定義了內(nèi)存模型施加的約束，然后列舉了與這些約束一致性的所有可能的結(jié)果。

低延遲補(bǔ)丁（2.6.38）

很久以前，在 2011 年之前，如果你想在 Linux 上進(jìn)行多媒體工作，你必須得有一個(gè)低延遲內(nèi)核。這主要適用于錄音時(shí)添加了許多實(shí)時(shí)效果（如對(duì)著麥克風(fēng)唱歌和添加混音，以及在耳機(jī)中無延遲地聽到你的聲音）。有些發(fā)行版，如 Ubuntu Studio，可靠地提供了這樣一個(gè)內(nèi)核，所以實(shí)際上這沒有什么障礙，這只不過是當(dāng)藝術(shù)家選擇發(fā)行版時(shí)的一個(gè)重要提醒。

然而，如果你沒有使用 Ubuntu Studio，或者你需要在你的發(fā)行版提供之前更新你的內(nèi)核，你必須跳轉(zhuǎn)到 rt-patches 網(wǎng)頁，下載內(nèi)核補(bǔ)丁，將它們應(yīng)用到你的內(nèi)核源代碼，編譯，然后手動(dòng)安裝。

后來，隨著內(nèi)核版本 2.6.38 的發(fā)布，這個(gè)過程結(jié)束了。Linux 內(nèi)核突然像變魔術(shù)一樣默認(rèn)內(nèi)置了低延遲代碼（根據(jù)基準(zhǔn)測(cè)試，延遲至少降低了 10 倍）。不再需要下載補(bǔ)丁，不用編譯。一切都很順利，這都是因?yàn)?Mike Galbraith 編寫了一個(gè) 200 行的小補(bǔ)丁。

對(duì)于全世界的開源多媒體藝術(shù)家來說，這是一個(gè)規(guī)則改變者。從 2011 年開始事情變得如此美好，到 2016 年我自己做了一個(gè)挑戰(zhàn)，在樹莓派 v1（型號(hào) B）上建造一個(gè)數(shù)字音頻工作站（DAW），結(jié)果發(fā)現(xiàn)它運(yùn)行得出奇地好。

RCU（2.5）

RCU，即讀-拷貝-更新Read-Copy-Update，是計(jì)算機(jī)科學(xué)中定義的一個(gè)系統(tǒng)，它允許多個(gè)處理器線程從共享內(nèi)存中讀取數(shù)據(jù)。它通過延遲更新但也將它們標(biāo)記為已更新來做到這一點(diǎn)，以確保數(shù)據(jù)讀取為最新內(nèi)容。實(shí)際上，這意味著讀取與更新同時(shí)發(fā)生。

典型的 RCU 循環(huán)有點(diǎn)像這樣：

1.刪除指向數(shù)據(jù)的指針，以防止其他讀操作引用它。

2. 等待讀操作完成它們的關(guān)鍵處理。

3. 回收內(nèi)存空間。

將更新階段劃分為刪除和回收階段意味著更新程序會(huì)立即執(zhí)行刪除，同時(shí)推遲回收直到所有活動(dòng)讀取完成（通過阻止它們或注冊(cè)一個(gè)回調(diào)以便在完成時(shí)調(diào)用）。

雖然 RCU 的概念不是為 Linux 內(nèi)核發(fā)明的，但它在 Linux 中的實(shí)現(xiàn)是該技術(shù)的一個(gè)定義性的例子。

合作（0.01）

對(duì)于 Linux 內(nèi)核創(chuàng)新的問題的最終答案永遠(yuǎn)是協(xié)作。你可以說這是一個(gè)好時(shí)機(jī)，也可以稱之為技術(shù)優(yōu)勢(shì)，稱之為黑客能力，或者僅僅稱之為開源，但 Linux 內(nèi)核及其支持的許多項(xiàng)目是協(xié)作與合作的光輝范例。

它遠(yuǎn)遠(yuǎn)超出了內(nèi)核范疇。各行各業(yè)的人都對(duì)開源做出了貢獻(xiàn)，可以說都是因?yàn)?Linux 內(nèi)核。Linux 曾經(jīng)是，現(xiàn)在仍然是自由軟件的主要力量，激勵(lì)人們把他們的代碼、藝術(shù)、想法或者僅僅是他們自己帶到一個(gè)全球化的、有生產(chǎn)力的、多樣化的人類社區(qū)中。