2025 年 Linux 內(nèi)核十大技術(shù)創(chuàng)新｜年終盤點(diǎn)

由此可見，這個(gè)檢索過程是相對(duì)于 xarray 而言是更快的，相對(duì)于 xarray 原先的 O(logN)，現(xiàn)在可認(rèn)為是 O(1)。原先 swapcache 雖然限制了每個(gè) address_space 的大小為 64MB，但是樹的深度還是可以達(dá)到 3 級(jí)的。

另外，由于一個(gè) cluster 的 swap table 的內(nèi)存都聚集在同一個(gè) page 里面，當(dāng) swap out 密集發(fā)生在同一個(gè) cluster 的時(shí)候，它能表現(xiàn)出更強(qiáng)的 locality 局部性，有利用減小 cache miss 等。xarray 的樹形結(jié)構(gòu)以及基于 slab 的內(nèi)存管理方式，則更可能在多個(gè) page 里面來回跳躍訪問。

xarray 的樹管理一個(gè)更廣闊的范圍，每個(gè) address_space 為 64MB，這意味著，會(huì)跨越多個(gè) cluster，64MB 的范圍需要統(tǒng)一管理和加鎖，并且 cluster 內(nèi)部的訪問也需要 cluster lock。而 swap table，本身不會(huì)垮 cluster，僅在一個(gè) cluster 內(nèi)部訪問，只需要對(duì) 2MB 的 cluster 本身加鎖。由此去掉了原先管理 xarray 樹形結(jié)構(gòu)的鎖需求。

最后，大道至簡，swap table 這種類似數(shù)組的設(shè)計(jì)思路，寫出來的代碼人人都能看得懂。

關(guān)于 swap table 內(nèi)存占用方面的優(yōu)化，在[PATCH 8/9] mm, swap: implement dynamic allocation of swap table 中，Chris 和 Kairui 實(shí)際安排了 swap table 的動(dòng)態(tài)釋放，在一個(gè) cluster 里面的 512 個(gè) slot 都沒人用的時(shí)候，這個(gè) cluster 的 swap table 可以釋放。

由于 swap table 的顯著優(yōu)勢(shì)來源于查詢路徑的縮短、locality 的提升、lock contention 的減小，相對(duì) xarray 加速了 swapcache 的查詢、修改等操作，屬于基礎(chǔ)設(shè)施的改善，其優(yōu)勢(shì)在服務(wù)器等場景會(huì)呈現(xiàn)較大的實(shí)用價(jià)值，對(duì)一些關(guān)鍵業(yè)務(wù)的吞吐量帶來提升。

TCP 零拷貝發(fā)送 DMABUF

Device Memory TCP (devmem TCP)完成了 2 個(gè)目標(biāo)：

• 通過網(wǎng)絡(luò)發(fā)送設(shè)備 memory。底層的設(shè)備 memory 采用 dma-buf 機(jī)制；

• 通過網(wǎng)絡(luò)接收設(shè)備 memory 并直接存入本地的設(shè)備 memory。

因此，它是一種 Direct-to-device 的網(wǎng)絡(luò)方法。

我們知道 dma-buf 提供了一種本機(jī)內(nèi)部設(shè)備與設(shè)備、設(shè)備與設(shè)備共享內(nèi)存的方法，之前筆者已經(jīng)在《)》中有論述。簡單地來說，dma_buf 可以實(shí)現(xiàn) buffer 在多個(gè)設(shè)備的共享，應(yīng)用可以把一片底層驅(qū)動(dòng) A 的 buffer 導(dǎo)出到用戶空間成為一個(gè) fd，也可以把 fd 導(dǎo)入到底層驅(qū)動(dòng) B。當(dāng)然，如果進(jìn)行 mmap() 得到虛擬地址，CPU 也是可以在用戶空間訪問到已經(jīng)獲得用戶空間虛擬地址的底層 buffer 的。

devmem TCP 實(shí)際上把 dma-buf 的傳輸擴(kuò)展到網(wǎng)絡(luò)上并非本機(jī)的設(shè)備、CPU 之間了。由于是 A 機(jī)器的 dma-buf 送到 B 機(jī)器的 dma-buf，這樣避免了設(shè)備的 dma-buf 和 host buffer 之間的拷貝。

跨節(jié)點(diǎn)的 device 到 device 的傳輸，在下面的一些應(yīng)用場景中可能受益：

• 分布式訓(xùn)練，即在不同主機(jī)上的機(jī)器學(xué)習(xí)加速器（如GPU）之間交換數(shù)據(jù)。

• 分布式 raw block storage 應(yīng)用與遠(yuǎn)程 SSD 傳輸大量數(shù)據(jù)。其中大部分?jǐn)?shù)據(jù)不需要主機(jī)處理。

相關(guān)的 patchset 主要由 Google 的 Mina Almasry 完成，Linux 6.12 中支持了 rx，而 6.16 內(nèi)核中，也支持了 TCP dmabuf 的 tx 路徑。接收端的網(wǎng)卡應(yīng)支持 header 的自動(dòng)分離，并且支持 flow steering 、RSS，確保目標(biāo)是 devmem 的網(wǎng)絡(luò)包能流向正確的 RX queue。

調(diào)度器時(shí)間片擴(kuò)展 time slice extension

想象用戶態(tài)的線程 A 拿到了 spinlock，由于用戶態(tài) spinlock 并不會(huì)像內(nèi)核態(tài) spinlock 那樣禁止搶占，完全有可能線程 B 搶占線程 A，線程 B 可能運(yùn)行很久，而假設(shè)線程 C 需要等待線程 A 的 spinlock 釋放，這個(gè) C 的等待可能是非常長的。

如果我們提供一個(gè)機(jī)制，比如線程 A 拿到了 spinlock，在 critical section 里面執(zhí)行的過程中，若發(fā)生時(shí)間片用完或者其他什么事情要搶占 A，調(diào)度器可以擴(kuò)展一點(diǎn)點(diǎn)時(shí)間片給 A，比如 50 微妙內(nèi)讓 A 不被搶占，則線程 A 大概率可以執(zhí)行完 critical section，從而規(guī)避一系列問題。而具體擴(kuò)展時(shí)間片的長度則可由新增的 rseq_slice_extension_nsec 這個(gè) sysctl 決定。

用戶空間線程通過 prctl() 顯式地告訴內(nèi)核，它需要時(shí)間片擴(kuò)展：

prctl(PR_RSEQ_SLICE_EXTENSION, PR_RSEQ_SLICE_EXTENSION_SET, +          PR_RSEQ_SLICE_EXT_ENABLE, 0, 0);

有一個(gè) per-cpu 的 Restartable sequences（簡稱rseq）供用戶態(tài)和內(nèi)核態(tài)交互，需要時(shí)間片擴(kuò)展的一個(gè)典型的用戶態(tài)偽代碼如下：

如果線程通過 prctl() 啟用了該機(jī)制，就可以把 rseq::slice_ctrl::request 設(shè)為 1 來請(qǐng)求延長當(dāng)前時(shí)間片。當(dāng)線程被中斷且內(nèi)核因此產(chǎn)生重新調(diào)度請(qǐng)求時(shí)，內(nèi)核看到了用戶態(tài)設(shè)置了 rseq::slice_ctrl::request =1，它可能選擇不立即把線程換下 CPU，而是批準(zhǔn)一次 rseq_slice_extension_nsec 時(shí)間片擴(kuò)展并直接返回用戶態(tài)繼續(xù)執(zhí)行。

當(dāng)內(nèi)核同意時(shí)間片擴(kuò)展時(shí)，會(huì)把 rseq::slice_ctrl::request 清零，并將 rseq::slice_ctrl::granted 置為 1，表示擴(kuò)展已批準(zhǔn)；如果在擴(kuò)展之后線程仍然被resched（被換下 CPU），內(nèi)核會(huì)再把 granted 位清零，用來通知用戶態(tài)這次擴(kuò)展已經(jīng)結(jié)束或失效。

基于 RSEQ 的時(shí)間片擴(kuò)展工作，主要由 Thomas Gleixner 和 Peter Zijlstra 完成。

multi-kernel

Cong Wang 在 LKML 發(fā)送了一個(gè) RFC 序列，支持 multi-kernel。multi-kernel 與容器、hypervisor 都有本質(zhì)不同,它在同一臺(tái)機(jī)器上并行運(yùn)行多個(gè) Linux kernel，每個(gè) kernel 獨(dú)占一部分硬件，并通過消息通信協(xié)作。

在 Cong Wang 建議的方法中，host kernel 管理 spawn kernel。

Host kernel 負(fù)責(zé)：硬件資源管理、創(chuàng)建 / 銷毀子 kernel、跨 kernel 協(xié)調(diào)。Spawn kernel 負(fù)責(zé)跑應(yīng)用、具備獨(dú)立調(diào)度 / 內(nèi)存 / IO 并與其他 kernel 隔離。Cong Wang 的 multi-kernel 實(shí)現(xiàn)可以概括為：

1. 用 kexec 在同機(jī)啟動(dòng)多個(gè) Linux

2. 用 CPU / 內(nèi)存 / IO 硬件分區(qū)做隔離

3. 用 IPI + 共享內(nèi)存通信

4. 用 hotplug + DT overlay 動(dòng)態(tài)調(diào)資源

5. 用硬件 queue 切分 IO

6. 每 workload 跑定制 kernel

這個(gè) multi-kernel 方案未來會(huì)走向何方、能否在 Linux 內(nèi)核上游社區(qū)引起足夠關(guān)注和投入，都會(huì)是很值得觀察的看點(diǎn)。

io_uring 的網(wǎng)絡(luò)零拷貝收包

由 Pavel Begunkov 和 David Wei 完成的工作，正式合入 Linux 內(nèi)核 6.15，為 io_uring 增加了零拷貝接收（zero-copy receive）支持，使數(shù)據(jù)能夠直接批量、快速地接收并寫入應(yīng)用程序內(nèi)存，而無需再從內(nèi)核內(nèi)存中拷貝一份。

io_uring 的零拷貝與 DPDK 有很大不同，DPDK 完全 bypass 了內(nèi)核，而 io_uring 這種內(nèi)核為 userspace 提供的 async I/O 模式，則仍然重用了內(nèi)核的網(wǎng)絡(luò)機(jī)制，如下圖，借鑒硬件的支持，payload 被硬件直接 DMA 到 userspace 的 buffers。

io_uring 提供了一種“混合旁路（hybrid bypass）”機(jī)制：在保持與 Linux 內(nèi)核體系緊密集成的同時(shí)，實(shí)現(xiàn)了顯著的性能提升。相比 DPDK 這種完全旁路（full bypass）方案，它在使用上更加便捷，對(duì)現(xiàn)有系統(tǒng)的侵入性也更低。

它的整個(gè)工作流程如下：

在 io_uring中，用戶和內(nèi)核通過 2 個(gè) queue 交互：SQ（Submission Queue）、CQ（Completion Queue）。

由于 DMA 要直接往 userspace 的 buffers 里面?zhèn)鬏敂?shù)據(jù)，所以 buffer 需要在內(nèi)核 pin 住，相關(guān) API 是：io_uring_register_buffers()。

與前面的 devmem TCP 相似，該機(jī)制也依賴于硬件的報(bào)文頭/數(shù)據(jù)分離（header/data split）、流量引導(dǎo)（flow steering）以及 RSS（接收端擴(kuò)展），以確保數(shù)據(jù)包頭部保留在內(nèi)核內(nèi)存中，而只有目標(biāo)流量才會(huì)被導(dǎo)向配置為零拷貝的硬件接收隊(duì)列。

io_uring dmabuf 讀寫支持

這個(gè) patchset 試圖讓存儲(chǔ)設(shè)備（如 NVMe）可以直接 DMA 到 dmabuf 所代表的內(nèi)存，而不是走用戶頁緩存 / copy 路徑。

用戶態(tài)發(fā)起：

    { dma_buf_fd, file_fd });

即：

• 提供 dmabuf fd

• 提供目標(biāo) file fd（如 nvme block）

發(fā)起讀：

io_uring_prep_read_fixed(..., reg_buf_idx);

注意這套能力不是給通用文件 I/O 準(zhǔn)備的，而是給高性能數(shù)據(jù)管線 / 設(shè)備直通 pipeline 用的，不是 ext4 / f2fs 等文件讀寫。

該 patchset 把 dmabuf 封裝成一種可被 block 層提交和 DMA 的 buffer 類型，讓存儲(chǔ)設(shè)備可以直接對(duì) dmabuf 做 DMA。主要實(shí)現(xiàn)原理（4 步）:

A.注冊(cè)：dmabuf → dma_token

用戶用 dmabuf fd 注冊(cè) io_uring buffer 時(shí)：

dma_buf_get()

dma_buf_attach(target_device)

dma_buf_map_attachment()

→ stable

然后封裝成一個(gè)內(nèi)部對(duì)象：dma_token，它代表一塊可 DMA 的共享內(nèi)存。

B. 提交 IO：新 iterator 類型

新增一種 buffer 迭代器：ITER_DMA_TOKEN

提交 read/write 時(shí)：

SQE → dma_token → iov_iter

讓 block 層識(shí)別這是 dmabuf，而不是用戶頁。

C. 構(gòu)建 bio / request

block 層改造后可以：

bio → dma_token → sg_table

不再依賴 page，而是直接用 dmabuf 的 scatter-gather 表。

D. Driver DMA

以 NVMe 為例：

sg_table → PRP / SGL → device DMA → dmabuf

實(shí)現(xiàn)存儲(chǔ)設(shè)備直接 DMA 到 dmabuf 內(nèi)存。

dmem cgroup

在較早的內(nèi)核中，cgroup 已經(jīng)可以管理普通系統(tǒng)內(nèi)存（RSS、swap 等），但缺少針對(duì) GPU / 加速器設(shè)備內(nèi)存的統(tǒng)一計(jì)量與限制機(jī)制。

dmem cgroup 是用來對(duì)“設(shè)備私有內(nèi)存（device memory）”做資源隔離與計(jì)量的 cgroup 控制器。它管的不是普通 DRAM，而是 GPU、accelerator 和其他的 device 本地內(nèi)存。dmem cgroup 目的在于：

• 讓 cgroup 能統(tǒng)計(jì)設(shè)備內(nèi)存使用量；

• 能針對(duì)這些內(nèi)存設(shè)置 min/low/max 限制；

• 能在資源過度使用時(shí)做 eviction（回收/驅(qū)逐）

在 Linux 6.14 中，DMEM cgroup 支持已經(jīng)集成到 Intel Xe 內(nèi)核圖形驅(qū)動(dòng)中，用于根據(jù) cgroup 層級(jí)限制顯存（vRAM）的使用。這個(gè)用于顯存內(nèi)存計(jì)數(shù)的 DMEM cgroup 代碼，也可以“輕松地”被其他依賴 TTM（Translation Table Maps）進(jìn)行內(nèi)存管理的內(nèi)核圖形驅(qū)動(dòng)復(fù)用。

dmem 的 cgroup 接口如下：

• dmem.current：當(dāng)前 cgroup 使用的 device memory 字節(jié)數(shù)；

• dmem.max, dmem.min, dmem.low： nested-keyed（支持層級(jí)鍵值），用于配置不同 cgroup 的內(nèi)存資源限制；

• dmem.capacity：顯示該內(nèi)存區(qū)域的最大容量，僅存在于 root。

dmem 的整個(gè)實(shí)現(xiàn)原理如下：

作者簡介

宋寶華，經(jīng)典讀書《Linux設(shè)備驅(qū)動(dòng)開發(fā)詳解》作者。Linux 主線內(nèi)核dma-mapping benchmark、SWAP、THP 的維護(hù)者或?qū)徍苏?，累?jì)給 Linux 主線內(nèi)核貢獻(xiàn)數(shù)百個(gè)補(bǔ)丁。在 Linux 調(diào)度器、內(nèi)存管理、ARM arch、DMA、中斷、驅(qū)動(dòng)等領(lǐng)域有廣泛的貢獻(xiàn)，是 SCHED_CLUSTER、PER_NUMA CMA、zswap 硬件壓縮解壓、ARM64 TLB batch unmap、swap entries 批量 unmap、mTHP swap-in、madvise PER_VMA lock 等特性的 author 或 co-author。

參考文獻(xiàn)：

[1]slab sheaves和barns

https://lore.kernel.org/linux-mm/20260123-sheaves-for-all-v4-0-041323d506f7@suse.cz/

[2]sched-ext sub-schedulers:

https://lore.kernel.org/lkml/20260121231140.832332-1-tj@kernel.org/

[3]代理執(zhí)行Proxy Execution:

https://lwn.net/ml/all/20250712033407.2383110-1-jstultz@google.com/

https://lwn.net/ml/all/20250722070600.3267819-1-jstultz@google.com/

[5]scheduler時(shí)間片擴(kuò)展：

https://lore.kernel.org/lkml/20251215155615.870031952@linutronix.de/

[6]tcp dmabuf tx零拷貝：

https://lore.kernel.org/netdev/20250508004830.4100853-1-almasrymina@google.com/

[7] io_uring zero_copy rx:

https://lwn.net/Articles/1004591/

[8] io_uring file->dmabuf:

https://lore.kernel.org/all/cover.1763725387.git.asml.silence@gmail.com/

[9]dmem cgroup:

https://lore.kernel.org/lkml/20241204134410.1161769-1-dev@lankhorst.se/

[10]swap table:

https://lore.kernel.org/linux-mm/20250822192023.13477-1-ryncsn@gmail.com/

https://lore.kernel.org/linux-mm/20250514201729.48420-25-ryncsn@gmail.com/

未來沒有前后端，只有 AI Agent 工程師。

這場十倍速的變革已至，你的下一步在哪？

4 月 17-18 日，由 CSDN 與奇點(diǎn)智能研究院聯(lián)合主辦「2026 奇點(diǎn)智能技術(shù)大會(huì)」將在上海隆重召開，大會(huì)聚焦 Agent 系統(tǒng)、世界模型、AI 原生研發(fā)等 12 大前沿專題，為你繪制通往未來的認(rèn)知地圖。

成為時(shí)代的見證者，更要成為時(shí)代的先行者。

奇點(diǎn)智能技術(shù)大會(huì)上海站，我們不見不散！