每年開(kāi)合并窗口的頭幾天社區(qū)里總會(huì)彌漫著一種既躁動(dòng)又緊張的氣氛。這次Linux 7.0的合并窗口也不例外。很多人一聽(tīng)到大版本號(hào)就興奮以為會(huì)看到什么天翻地覆的改變但真正參與過(guò)內(nèi)核開(kāi)發(fā)或者長(zhǎng)期跟蹤主線的人心里都清楚版本號(hào)從6跳到7更多是多年技術(shù)積累的自然結(jié)果而不是某一天突然推倒重建。我從合并窗口第一天就在盯各個(gè)子系統(tǒng)的pull request每天翻郵件列表和Linus的提交歷史這一輪看下來(lái)我的總結(jié)是7.0不是一場(chǎng)革命而是一次對(duì)過(guò)去幾年技術(shù)債的集中償還同時(shí)也是若干關(guān)鍵方向從可用走向好用的轉(zhuǎn)折點(diǎn)。這篇東西不是那種泛泛的版本發(fā)布新聞稿而是想從調(diào)度器、內(nèi)存管理、文件系統(tǒng)、網(wǎng)絡(luò)、平臺(tái)支持和安全加固幾個(gè)維度把7.0合并窗口里真正值得關(guān)注的東西拆開(kāi)講清楚。不管你是跑服務(wù)器的運(yùn)維、搞嵌入式的工程師還是做桌面Linux的開(kāi)發(fā)者這輪合并窗口里都有與你相關(guān)的改動(dòng)。我會(huì)把每個(gè)改動(dòng)背后的為什么也一并說(shuō)清楚畢竟只看commit標(biāo)題不看動(dòng)機(jī)等于沒(méi)看。1. 大版本號(hào)的含金量7.0合并窗口究竟帶來(lái)了什么1.1 合并窗口本身是怎么回事先給不熟悉內(nèi)核開(kāi)發(fā)流程的讀者補(bǔ)個(gè)基礎(chǔ)。Linux內(nèi)核每個(gè)版本號(hào)背后都對(duì)應(yīng)一個(gè)固定的開(kāi)發(fā)節(jié)奏合并窗口merge window大約持續(xù)兩周在這兩周里各個(gè)子系統(tǒng)的維護(hù)者會(huì)把過(guò)去一段時(shí)間積累的補(bǔ)丁通過(guò)pull request提交給LinusLinus逐個(gè)合并進(jìn)主線。合并窗口關(guān)閉后進(jìn)入大概8到10周的穩(wěn)定期期間只修bug、不添新功能最后發(fā)布正式版。所以看一個(gè)版本的分量最直接的辦法就是看合并窗口里合入了什么。7.0的合并窗口在流程上沒(méi)有異常還是標(biāo)準(zhǔn)的兩周。但有意思的是Linus在7.0-rc1發(fā)布郵件里特別提到了一句這次合并的補(bǔ)丁數(shù)量不算瘋狂但覆蓋面很廣而且有大量改動(dòng)是清理欠賬性質(zhì)的。這句話值得細(xì)品。它意味著7.0的定位不是開(kāi)新坑而是把過(guò)去幾個(gè)版本埋下的優(yōu)化和重構(gòu)真正收口。1.2 這一輪的補(bǔ)丁構(gòu)成與占比從整體數(shù)字看7.0合并窗口改動(dòng)的文件數(shù)量和行數(shù)在6.x系列中屬于中等偏上水平。pull request主要集中在這幾個(gè)領(lǐng)域調(diào)度器、內(nèi)存管理、文件系統(tǒng)、網(wǎng)絡(luò)、DRM驅(qū)動(dòng)、平臺(tái)架構(gòu)代碼以及RISC-V相關(guān)的支持。其中有一個(gè)明顯趨勢(shì)——驅(qū)動(dòng)代碼的占比仍然很高這在過(guò)去幾代內(nèi)核里一直是常態(tài)因?yàn)閮?nèi)核永遠(yuǎn)要追趕新硬件。真正讓內(nèi)核開(kāi)發(fā)者興奮的反而是那些非驅(qū)動(dòng)的部分調(diào)度器的收尾優(yōu)化、folio化的繼續(xù)推進(jìn)、sched_ext逐步走向生產(chǎn)可用。我特別留意了一個(gè)細(xì)節(jié)這輪合并窗口里新功能的比例明顯低于改進(jìn)穩(wěn)定性和性能的比例。這在過(guò)去幾次6.x大版本里也出現(xiàn)過(guò)但7.0更明顯。舉個(gè)例子內(nèi)存管理子系統(tǒng)的改動(dòng)里大部分是在優(yōu)化現(xiàn)有機(jī)制比如folio的推廣范圍、多代LRU在多內(nèi)存控制組下的表現(xiàn)而不是引入全新的回收算法。這種不求有功但求無(wú)過(guò)的思路恰好是一個(gè)大版本該有的姿態(tài)。另外RISC-V相關(guān)的補(bǔ)丁繼續(xù)快速增加。這個(gè)趨勢(shì)從6.x中期開(kāi)始就很明顯7.0窗口里RISC-V的各類平臺(tái)支持、SMP調(diào)度修正和newlib/toolchain適配都有不小動(dòng)靜。如果你在做嵌入式選擇新架構(gòu)7.0之后再談RISC-V成熟度已經(jīng)和幾年前的ARM64差不多了。2. 調(diào)度器從EEVDF到sched_ext性能與定制兩頭下注2.1 EEVDF的邊界行為補(bǔ)全調(diào)度器一直是內(nèi)核社區(qū)話語(yǔ)權(quán)最大的子系統(tǒng)之一。6.6引入EEVDF調(diào)度器替代了服役多年的CFS當(dāng)時(shí)引起不小爭(zhēng)論。經(jīng)過(guò)一年多、十來(lái)個(gè)版本的打磨7.0合并窗口里EEVDF的改動(dòng)集中在幾個(gè)非常細(xì)節(jié)的地方lag進(jìn)程虛擬運(yùn)行時(shí)間的偏差的累計(jì)和補(bǔ)償邊界、喚醒搶占的時(shí)機(jī)判斷、以及task group場(chǎng)景下的公平性修正。先說(shuō)lag這個(gè)概念的通俗化理解。EEVDF里每個(gè)任務(wù)都有一個(gè)virtual deadline調(diào)度器總是選deadline最小的任務(wù)運(yùn)行。當(dāng)一個(gè)任務(wù)被搶占或者主動(dòng)睡眠時(shí)它實(shí)際獲得的CPU時(shí)間和理想應(yīng)得時(shí)間之間的差距就是lag。如果lag處理不當(dāng)會(huì)出現(xiàn)兩種情況要么任務(wù)醒來(lái)后瘋狂搶CPU要么一直排不上隊(duì)。7.0里做的重點(diǎn)工作就是把lag在task group嵌套場(chǎng)景下的傳遞邏輯補(bǔ)完整。這種問(wèn)題在普通桌面場(chǎng)景下根本看不出來(lái)但在容器混部、多人共享服務(wù)器上表現(xiàn)就是部分cgroup下的長(zhǎng)尾延遲抖動(dòng)。我過(guò)去在內(nèi)部壓測(cè)環(huán)境里見(jiàn)過(guò)類似現(xiàn)象修復(fù)這類問(wèn)題靠benchmark往往發(fā)現(xiàn)不了必須結(jié)合真實(shí)業(yè)務(wù)負(fù)載。這也是為什么這類補(bǔ)丁每次合入我都會(huì)多看兩眼。2.2 sched_ext正式走向生產(chǎn)sched_extSCX是這兩年調(diào)度器領(lǐng)域最大的變量。它通過(guò)BPF允許用戶加載自定義調(diào)度策略把調(diào)度器從內(nèi)核固定的黑盒變成了可編程模塊。Meta一直在推進(jìn)這個(gè)方向因?yàn)樗麄冇写罅繑?shù)據(jù)中心負(fù)載需要針對(duì)特定模型調(diào)優(yōu)但又不愿意為每個(gè)負(fù)載都改內(nèi)核、編內(nèi)核。7.0合并窗口對(duì)sched_ext的改動(dòng)主要是兩類一類是基礎(chǔ)設(shè)施穩(wěn)定化比如BPF調(diào)度器與SCX運(yùn)行隊(duì)列之間的狀態(tài)同步、cpu hotplug時(shí)調(diào)度器切換的競(jìng)態(tài)修復(fù)另一類是針對(duì)rqrun queue鎖粒度的優(yōu)化。鎖粒度這東西是調(diào)度器性能的隱形天花板SCX早期版本為了靈活性在rq鎖上做了不少妥協(xié)現(xiàn)在明顯在往回補(bǔ)課。我個(gè)人的判斷是sched_ext不會(huì)完全取代EEVDF它的價(jià)值在于讓頭部互聯(lián)網(wǎng)公司能夠針對(duì)自己的混部場(chǎng)景寫幾百行BPF代碼就拿到幾個(gè)百分點(diǎn)的吞吐收益。對(duì)絕大多數(shù)普通用戶來(lái)說(shuō)EEVDF還是默認(rèn)值但7.0把SCX的門檻降到了可以認(rèn)真評(píng)估的程度。2.3 負(fù)載均衡與功耗的取舍這輪窗口里還有個(gè)容易被忽略的點(diǎn)SCHED_*系列在負(fù)載均衡上的改動(dòng)以及和cpufreq調(diào)頻器的聯(lián)動(dòng)。簡(jiǎn)單說(shuō)調(diào)度器不僅要決定誰(shuí)跑還要讓CPU頻率控制器有足夠的信息去決定跑多快。7.0里針對(duì)睡眠喚醒場(chǎng)景補(bǔ)了不少頻點(diǎn)預(yù)測(cè)邏輯目標(biāo)是減少喚醒后頻率拉不起來(lái)導(dǎo)致卡頓的情況。這在移動(dòng)設(shè)備和筆記本上的體感差異會(huì)比較明顯。如果你要給用戶側(cè)內(nèi)核升級(jí)我建議把這一點(diǎn)列入測(cè)試項(xiàng):用幾臺(tái)不同類型筆記本跑同版本內(nèi)核觀察空閑喚醒時(shí)的延遲和功耗變化。原因是這類改動(dòng)常常在某個(gè)特定硬件組合上出現(xiàn)回歸社區(qū)測(cè)試覆蓋不到所有機(jī)型。3. 內(nèi)存管理folio化與多代LRU的最后一公里3.1 folio替換帶來(lái)的鎖競(jìng)爭(zhēng)改善folio這個(gè)概念對(duì)很多人來(lái)說(shuō)可能還比較新。它本質(zhì)上是把內(nèi)核管理內(nèi)存的基本單位從單個(gè)page通常4KB提升到一個(gè)連續(xù)物理頁(yè)集合讓存儲(chǔ)層、文件系統(tǒng)、頁(yè)緩存可以以更大的粒度做操作減少元數(shù)據(jù)開(kāi)銷和鎖競(jìng)爭(zhēng)。6.x系列一直在擴(kuò)大folio的使用范圍7.0合并窗口里這項(xiàng)工作繼續(xù)推進(jìn)尤其是在page cache的讀路徑和內(nèi)存映射mmap的頁(yè)表操作上。這部分的收益用數(shù)據(jù)說(shuō)話會(huì)非常明顯。在高并發(fā)文件讀取場(chǎng)景下folio化程度越高i_mmap鎖的競(jìng)爭(zhēng)就越少。有同事在48核機(jī)器上做過(guò)對(duì)比測(cè)試開(kāi)folio路徑的吞吐比完全回退到單頁(yè)路徑能差出20%以上。7.0沒(méi)有做什么顛覆性的內(nèi)存管理改動(dòng)但僅憑folio范圍的擴(kuò)大就足以讓很多存儲(chǔ)密集場(chǎng)景受益。3.2 mglru面向內(nèi)存壓力場(chǎng)景的補(bǔ)強(qiáng)多代LRUmglru從6.1合入到現(xiàn)在已經(jīng)過(guò)了實(shí)驗(yàn)期但在內(nèi)存壓力極端場(chǎng)景下還是有不少粗糙的邊角。7.0合并窗口里針對(duì)multi-cgroup環(huán)境下的頁(yè)表掃描做了優(yōu)化核心是減少在高內(nèi)存壓力時(shí)反復(fù)掃描無(wú)用頁(yè)表項(xiàng)的現(xiàn)象。用大白話說(shuō)舊LRU在內(nèi)存不夠時(shí)需要遍歷很多頁(yè)來(lái)決定誰(shuí)先被殺mglru通過(guò)代際劃分縮小了掃描范圍但多cgroup場(chǎng)景下仍然可能出現(xiàn)某個(gè)cgroup干擾全局回收的情況這輪補(bǔ)丁就是修這類問(wèn)題。還有一個(gè)方向值得關(guān)注內(nèi)存回收與寫入回刷writeback的聯(lián)動(dòng)。7.0里對(duì)dirty page的回收策略做了細(xì)節(jié)調(diào)整讓回收器在有大量臟頁(yè)時(shí)更早觸發(fā)寫回避免在內(nèi)存耗盡邊緣出現(xiàn)長(zhǎng)時(shí)間卡頓。這個(gè)改動(dòng)對(duì)跑數(shù)據(jù)庫(kù)類負(fù)載的服務(wù)器意義很大因?yàn)槟悴幌肟吹絻?nèi)存夠但回收慢導(dǎo)致的假死狀態(tài)。3.3 NUMA與自動(dòng)平衡的長(zhǎng)期糾纏NUMA非一致內(nèi)存訪問(wèn)的自動(dòng)平衡在大型服務(wù)器上是個(gè)老問(wèn)題。7.0合并窗口里有一個(gè)持續(xù)了多輪討論的補(bǔ)丁系列聚焦于減少do_numa_page路徑上的頁(yè)表鎖。簡(jiǎn)單講當(dāng)任務(wù)從一個(gè)NUMA節(jié)點(diǎn)遷移到另一個(gè)節(jié)點(diǎn)時(shí)它訪問(wèn)的頁(yè)也需要跟著遷移或remap這個(gè)過(guò)程要頻繁操作頁(yè)表。在幾百線程的數(shù)據(jù)庫(kù)場(chǎng)景里頁(yè)表鎖很容易成為瓶頸。7.0的改動(dòng)把部分頁(yè)表操作延后到更安全的時(shí)機(jī)執(zhí)行代價(jià)是內(nèi)存訪問(wèn)的局部性判斷會(huì)稍微滯后但對(duì)吞吐的正面收益通常更大。對(duì)于跑內(nèi)存密集型工作負(fù)載的團(tuán)隊(duì)我的建議是在升級(jí)7.0后做一次跨NUMA訪問(wèn)的基準(zhǔn)測(cè)試重點(diǎn)看ldelec等字節(jié)碼和鎖競(jìng)爭(zhēng)指標(biāo)。這類改動(dòng)如果不專門測(cè)很容易被看起來(lái)沒(méi)變的觀察糊弄過(guò)去。4. 文件系統(tǒng)與存儲(chǔ)穩(wěn)定化比新特性更重要4.1 Bcachefs從能用走向可靠Bcachefs在6.7合入主線時(shí)社區(qū)的態(tài)度一直是拭目以待。這幾年它在穩(wěn)定性上的口碑隨著版本迭代慢慢好轉(zhuǎn)——但好轉(zhuǎn)和可靠之間還有距離。7.0合并窗口里Bcachefs的改動(dòng)集中在快照性能、自我修復(fù)和日志恢復(fù)幾個(gè)方向。具體說(shuō)快照?qǐng)鼍跋翨cachefs要處理多級(jí)快照的COW關(guān)系7.0里補(bǔ)了不少在快照鏈很長(zhǎng)時(shí)出現(xiàn)死鎖和數(shù)據(jù)不一致的修復(fù)。自我修復(fù)則是指它能在后臺(tái)持續(xù)校驗(yàn)數(shù)據(jù)、發(fā)現(xiàn)并修復(fù)損壞塊這本來(lái)是貼靠存儲(chǔ)廠商的關(guān)鍵賣點(diǎn)但實(shí)現(xiàn)不好會(huì)拖垮性能。這輪的改動(dòng)把后臺(tái)修復(fù)的I/O優(yōu)先級(jí)做低避免搶正常業(yè)務(wù)IO。如果你正在評(píng)估把生產(chǎn)服務(wù)器切到Bcachefs我的態(tài)度還是可以測(cè)試但別把所有雞蛋放一個(gè)籃子里。它的元數(shù)據(jù)設(shè)計(jì)和數(shù)據(jù)布局有自己的邏輯適合解決ZFS/Btrfs不擅長(zhǎng)的問(wèn)題但穩(wěn)定性還需要多幾個(gè)發(fā)布周期的沉淀。4.2 EROFS與鏡像場(chǎng)景的新需求EROFS在只讀鏡像、Android分區(qū)、容器鏡像場(chǎng)景里越來(lái)越常見(jiàn)。7.0合并窗口里針對(duì)EROFS的改動(dòng)主要圍繞壓縮算法和多線程并行解壓。EOFS的定位是高性能只讀它需要在壓縮率和隨機(jī)讀延遲之間取平衡。新改動(dòng)在decompression上做了更細(xì)的并發(fā)控制對(duì)高核數(shù)服務(wù)器讀取容器鏡像有直接幫助。如果你用containerd或podman跑大規(guī)模服務(wù)7.0之后可以重新跑一遍鏡像拉取和冷啟動(dòng)測(cè)試。EROFS在啟動(dòng)場(chǎng)景尤其是在高并發(fā)下解壓瓶頸上的表現(xiàn)很可能有可見(jiàn)提升。4.3 NVMe與塊層的效率改進(jìn)存儲(chǔ)層還有個(gè)不那么亮眼但很實(shí)在的改動(dòng)塊層的bioblock I/O請(qǐng)求合并邏輯優(yōu)化。這在多隊(duì)列NVMe場(chǎng)景下能減少ioctl的上下文切換和鎖開(kāi)銷。7.0里針對(duì)多隊(duì)列設(shè)備的請(qǐng)求分發(fā)做了進(jìn)一步的親和性調(diào)整讓同一CPU上的應(yīng)用提交的IO更傾向于在同一個(gè)隊(duì)列上完成從而利用CPU本地緩存提升吞吐。對(duì)數(shù)據(jù)庫(kù)、分布式存儲(chǔ)這類重IO場(chǎng)景塊層的行為直接決定了尾延遲。7.0這幾處改動(dòng)合入后建議跑一次fio和真實(shí)業(yè)務(wù)混合的壓測(cè)觀察P99/P999延遲曲線是否有改善。5. 網(wǎng)絡(luò)與異步IOio_uring繼續(xù)拓展邊界5.1 io_uring收尾工作io_uring從5.1問(wèn)世以來(lái)演進(jìn)速度一直非常快。7.0合并窗口里io_uring的改動(dòng)按量來(lái)說(shuō)不算多但方向很聚焦進(jìn)一步減少內(nèi)存開(kāi)銷和系統(tǒng)調(diào)用路徑上的檢查成本。比如對(duì)固定緩沖registered buffer和固定文件fixed file的重用邏輯做了優(yōu)化減少每筆IO在元組匹配上的開(kāi)銷。對(duì)真正用io_uring寫服務(wù)的人來(lái)說(shuō)這些改動(dòng)的意義在于同樣的文件描述符和緩沖池在長(zhǎng)時(shí)間運(yùn)行后內(nèi)存碎片化的影響會(huì)更小。我見(jiàn)過(guò)不少用io_uring跑網(wǎng)絡(luò)代理的項(xiàng)目跑到后期性能下降調(diào)查下來(lái)都是因?yàn)楣潭ň彌_區(qū)在多次reclaim后地址連續(xù)性和映射關(guān)系劣化。7.0這輪改動(dòng)對(duì)這類場(chǎng)景是有利的。5.2 TCP與WiFi驅(qū)動(dòng)層面網(wǎng)絡(luò)協(xié)議棧方面7.0窗口里TCP有若干擁塞控制細(xì)節(jié)的調(diào)整集中在BBR與CUBIC切換時(shí)的平滑過(guò)渡以及SACK壓縮邏輯對(duì)極端丟包情況的容錯(cuò)。這些都屬于不聲不響但關(guān)鍵時(shí)刻救命的改動(dòng)。對(duì)于長(zhǎng)時(shí)間維持大量長(zhǎng)連接的網(wǎng)關(guān)或代理節(jié)點(diǎn)值得驗(yàn)證一下混合擁塞控制算法存在時(shí)的吞吐穩(wěn)定性。WiFi驅(qū)動(dòng)方面新的ath12k、mt76平臺(tái)支持繼續(xù)增多6.x時(shí)代出現(xiàn)的WiFi 7802.11be支持也在繼續(xù)完善。如果你在做路由器固件的內(nèi)核適配7.0對(duì)WiFi 7的MLOmulti-link operation支持比之前版本完整不少。不過(guò)新版重置的mac80211接入點(diǎn)邏輯改動(dòng)也比較大自定義驅(qū)動(dòng)和固件配合需要同步升級(jí)。6. 平臺(tái)支持與安全加固激進(jìn)與保守并存6.1 新SoC和顯卡支持7.0合并窗口的DRM和平臺(tái)代碼部分依舊是硬件追趕者的節(jié)奏。amdgpu新增了若干新一代RDNA架構(gòu)的顯示管線支持Intel的Xe驅(qū)動(dòng)則繼續(xù)填補(bǔ)新平臺(tái)和電源管理上的空白。對(duì)桌面用戶來(lái)說(shuō)這一輪里顯卡驅(qū)動(dòng)的實(shí)際體驗(yàn)提升往往不在跑分上而在休眠喚醒、顯示器熱插拔和顏色管理的穩(wěn)定性上。平臺(tái)方面RISC-V繼續(xù)是增長(zhǎng)最快的架構(gòu)。新增的SoC平臺(tái)支持覆蓋了從低功耗微控制器到邊緣服務(wù)器的多個(gè)層次而且SMP性能調(diào)優(yōu)的補(bǔ)丁越來(lái)越密集。這意味著RISC-V在7.0時(shí)代已經(jīng)不只是跑玩具級(jí)Linux而是可以承載真實(shí)業(yè)務(wù)的系統(tǒng)。6.2 安全機(jī)制的變化這一輪安全相關(guān)的改動(dòng)有幾個(gè)點(diǎn)值得強(qiáng)調(diào)。一是內(nèi)核組件在Rust語(yǔ)言上的進(jìn)一步落地從驅(qū)動(dòng)逐漸擴(kuò)展到核心基礎(chǔ)設(shè)施的部分關(guān)鍵模塊。Rust在內(nèi)存安全上的收益是實(shí)打?qū)嵉牡惨宄ust化了不意味著沒(méi)有邏輯bug只是把一整類緩沖區(qū)溢出和懸垂指針問(wèn)題從根源上掐掉。二是KCFI內(nèi)核控制流完整性在支持范圍和性能開(kāi)銷上的繼續(xù)優(yōu)化這讓攻擊者更難通過(guò)劫持間接調(diào)用來(lái)提權(quán)。還有一類安全改動(dòng)容易被忽略末級(jí)緩存LLC的隔離和刷新策略調(diào)整。對(duì)付側(cè)信道攻擊比如跨核心的緩存時(shí)間攻擊需要在調(diào)度和緩存之間做取舍7.0的改動(dòng)方向是在保持大部分場(chǎng)景性能的前提下適當(dāng)增加敏感操作之間的緩存邊界。這些改動(dòng)對(duì)安全研究員和高安全要求的云環(huán)境價(jià)值很大。要強(qiáng)調(diào)的是這類能力屬于平時(shí)無(wú)感、出事時(shí)救命的類型。我建議安全團(tuán)隊(duì)在升級(jí)后重點(diǎn)檢查內(nèi)核配置中的各項(xiàng)KCFI和執(zhí)行權(quán)限位設(shè)置是否按預(yù)期生效同時(shí)配合自己的安全加固基線做回歸。7. 對(duì)開(kāi)發(fā)者的升級(jí)建議和觀察清單7.1 升級(jí)前要關(guān)注什么如果你計(jì)劃從6.x升級(jí)到7.0我的建議是不要只關(guān)注新特性列表。先做這幾件事第一檢查你的內(nèi)核配置里是否啟用了可能被移除或變更的選項(xiàng)尤其是早期平臺(tái)驅(qū)動(dòng)不少老型號(hào)ARM SoC的驅(qū)動(dòng)被移到了staging或刪除第二重新審視你的schedutil和cpufreq相關(guān)配置因?yàn)檎{(diào)度器和調(diào)頻的聯(lián)動(dòng)邏輯有明顯改動(dòng)第三跑一遍你業(yè)務(wù)里的長(zhǎng)尾延遲基準(zhǔn)而不是只看平均吞吐。對(duì)于生產(chǎn)服務(wù)器強(qiáng)烈推薦先在子集環(huán)境運(yùn)行至少一個(gè)發(fā)布周期比如-rc5之后、正式版發(fā)布前再切全量。社區(qū)雖然在過(guò)去幾個(gè)版本里已經(jīng)把大部分回歸提前攔住了但在驅(qū)動(dòng)和特定硬件組合上小概率問(wèn)題依然存在。7.2 值得繼續(xù)跟蹤的方向7.0合并窗口關(guān)上的那一刻幾個(gè)長(zhǎng)期趨勢(shì)已經(jīng)有了明確水位線sched_ext的生態(tài)會(huì)繼續(xù)擴(kuò)大未來(lái)路由器、邊緣網(wǎng)關(guān)甚至桌面管理器都可能出現(xiàn)自定義調(diào)度策略mglru的收尾會(huì)讓極端內(nèi)存壓力場(chǎng)景下的用戶體驗(yàn)顯著改善EROFS在容器工具鏈里的整合度會(huì)更高RISC-V平臺(tái)支持會(huì)在下一個(gè)版本里全面開(kāi)花。如果你做的是內(nèi)核相關(guān)開(kāi)發(fā)我建議重點(diǎn)讀幾個(gè)系列調(diào)度器里關(guān)于lag語(yǔ)義的討論內(nèi)存管理里folio進(jìn)一步推廣的RFC以及io_uring在權(quán)限模型上的演進(jìn)。這些內(nèi)容的討論密度往往比最終合入的commit本身更有信息量。我的個(gè)人習(xí)慣是每輪合并窗口結(jié)束后都會(huì)把郵件列表里L(fēng)WN的總結(jié)和幾個(gè)維護(hù)者的年度報(bào)告放一起存檔等半年后再回看。7.0這輪給我的總體感受是克制二字——沒(méi)有為了刷版本號(hào)而堆功能而是踏實(shí)地把過(guò)去幾年埋下的伏筆兌現(xiàn)了一半。剩下那半會(huì)在7.x的后續(xù)小版本里以更平滑的方式繼續(xù)落地。對(duì)用戶而言這反而是最健康的狀態(tài)。