2025 年 Linux 内核十大技术创新｜年终盘点
从明天起，做一个幸福的人。喂马，劈柴，周游世界。从明天起，关心粮食和蔬菜。我有一所房子，面朝大海，春暖花开。
——海子《面朝大海，春暖花开》
2026 农历新年的钟声即将敲响，在这全球共庆的跨年时刻，Linux 内核年度十大技术创新盘点如约而至。
回望过去的一年，平凡的日子里夹杂着些许苦涩与无奈。每一个渺小的个体，无论心中藏着怎样的悲伤或喜悦，都让它随风而去吧。新的一年里，纵然现实仍有诸多束缚，也愿诸君心底已然面朝大海，春暖花开。
过去的一年，内核开发者们废寝忘食地沉浸在代码的纯粹世界中，不断提交patch，推动 Linux 内核前行。
本文将盘点其中最具代表性的十个 patchset:
1
slab per-CPU cache机制：Sheaves(一捆)和barns(谷仓)
2
sched_ext: cgroup sub-scheduler支持
3
代理执行proxy-execution以解决优先级翻转
4
swap table替代xarray
5
TCP零拷贝发送DMABUF
6
调度器时间片扩展time slice extension
7
multi-kernel
8
io_uring的网络零拷贝收包
9
io_uring dmabuf读写支持
10
dmem cgroup
下面一一展开描述。
slab per-CPU cache 机制：Sheaves(一捆)和barns(谷仓)
内存管理的 buddy 是有 pcp(Per-CPU Page frame cache) 的，针对 buddy 申请和释放的内存，维护一定量的 Per-CPU 的 free 内存 list，以减小每次都从底层 buddy 获取、释放 pages 的锁竞争：
对于 Linux 内核 kmalloc/kfree 底层的 slab，实际上我们也需要类似的 per-CPU 机制，来减小 object 申请和释放时候跨 CPU 的锁竞争和跨 CPU 的 cache 同步等开销。Vlastimil Babka 的 patchset，把“农场”的 Sheaves 和 Barns 概念借用到内核中，以支撑 slab 的 per-CPU cache 能力。
(图源：https://www.reddit.com/r/linux/comments/1nd8hav/what_that_means/)
Sheaves（束/捆）
字面意思是 “麦束”或 “一捆”，内核中指每个 CPU 本地的一小批 slab object缓存，用于加快本地分配/释放，减少锁竞争。是一种 per‑CPU 对象缓存，用来快速满足分配和释放请求。每个 CPU 维护两个小缓存（主 sheaf 和备用 sheaf），只要其中有对象，就直接返回/放回，不用去访问全局 slab 页或锁住别人，从而提高性能。分配/释放 object 大多数情况下是 本地、无锁的操作。
Barns（谷仓/仓库）
字面意思是 “谷仓”或 “仓库”，内核中指 全局 slab 池（但是是按照NUMA来管理的），供各个 CPU 的 sheaves 补充或回收，其功能是保证全局内存平衡，处理 sheaves 空或满的情况。barn 里有两类队列：full（装满对象的 sheaf）和 empty（空 sheaf），方便快速交换。
当某个 CPU 的 sheaves 满了或空了时，才涉及到 barn（谷仓）：
空sheaves：如果分配时 sheaves 空了，CPU 会尝试从 barn取一个 full sheaf。
满 sheaves：释放时 sheaves 都满了，会往 barn 里放一个 full sheaf 或把 sheaf 里的对象回写 slab 页面。
sched_ext: cgroup sub-scheduler 支持
这个 patchset 来自 Tejun Heo，为 sched_ext 增加了基于 cgroup 的子调度器（sub-scheduler）支持，使多个 BPF 调度器可以按 cgroup 层级结构协同运行：父调度器负责在不同 cgroup（租户/分区）之间分配 CPU 资源，子调度器负责各自 cgroup 内部的任务调度。这样系统就能按 workload 分区部署不同调度策略，满足多租户服务器和混部场景下对差异化调度（如延迟优先、吞吐优先等）的需求。比如不同的业务类型需求不一样，可以组成如下层次化的调度系统：
上图中，数据库系统的调度器能够理解查询的优先级和锁持有者的重要性（criticality）。虚拟机管理程序（VMM）可以与虚拟机内部的调度器协同，并智能地安排 vCPU 的位置。游戏引擎的调度器则知道渲染的截止时间，以及哪些线程对延迟敏感（latency-critical）。
每个 cgroup 可绑定一个 scheduler，父 scheduler 通过 dispatch 驱动子 scheduler 获得 CPU 时间，从而形成自顶向下的带宽分配 + 组内调度两级（或多级）结构，目前控制最大深度SCX_SUB_MAX_DEPTH = 4，防止调度路径过深、复杂度失控。
父 scheduler 在ops.dispatch里面决定哪个子 scheduler 运行以及给多少 CPU 时间。每个 sub-scheduler 都是独立实例，维护自己的运行参数,典型包括：默认时间片（time slice）、watchdog（卡死检测）、bypass mode（旁路模式）、本地 DSQ / runqueue 状态，因此,每个 cgroup可能成为一个独立调度域。父 scheduler的ops.dispatch可以调用 scx_bpf_sub_dispatch来触发子调度器的 dispatch，child 再选具体 task 运行。
tj 的 patchset 一共 34 个 patch：
代理执行 proxy-execution 以解决优先级翻转
如下图，P2 求 P1 的持有的锁，但是 P1 因为被抢占（时间片耗尽等原因）拿不到 CPU，从而 P2 要等很久才拿到锁，造成用户层面的卡顿体验。
代理执行的逻辑是，在调度层面把调度上下文和执行上下文分开。假设 P2 上下求锁而不得的时候，它会在它的 task_struct 里面记录 block_on 什么任务上面，在这里是 P1，于是 P2 会把自己的时间（调度上下文）“捐献”给 P1 去跑，P1 用 P2 捐献给自己的时间执行 P1 的代码（执行上下文）。
如上图所示，现在 P2 把时间捐给 P1 后，很快 P1 就把锁释放了。然而，魔鬼都在细节里，实际上，这里面有一些复杂的问题：
1. P2 把时间捐给 P1 后，P1 运行的过程中说不定会要求持有第 2 个锁等待，因此再次阻塞；显然我们需要把这个捐赠的过程变成一个链条。
2. P1 和 P2 可能不在一个 CPU 上，不在一个 runqueue 上面，跨国没法捐。所以我们很可能要把 P2 的调度上下文先迁移到 P1 上面去给 P1。
目前 6.17 合入的是一个 baby step，支持 P1 和 P2 本身在一个 CPU 上的时候的代理执行，目前显然没有实际意义，因为哪怕手机只有 8 个核，P1 和 P2 在同一个 CPU 的机会也很渺茫。但是，基于社区迭代开发的流程意义上来讲，这是极其重大的一个进展，它为 proxy execution 的未来开启了一扇大门。关于 Donor Migration 的支持，已成为一个单独的 patchset 来开发和 review。
proxy execution 主要由 Google 的 John Stultz 领导开发，由多名 developer 联合贡献，其首要目的在于改善 Android 系统的用户体验。
swap table 替代 xarray
swap table 本质上是一种替代目前 xarray 管理方式的，更简洁、更高性能的 swapcache 实现。
在 Linux 内核中，我们用 xarray 来描述一个文件的 pagecache 命中情况。比如一个很大的文件，在 pagecache 中只命中了很少的页。拿到相应位置的文件 offset，则可通过 xarray 树形结构的逐级查询(类似多级页表从虚拟地址到物理地址的方式)来获知这些命中页的指针，而其他绝大多数区间由于未在 pagecache 命中，并不需要在 xarray 上分配出元数据。
在 Linux 内核的实现中，针对匿名页，也存在一种与文件页的 pagecache 类似的东西，叫 swapcache。swapcache 可简单理解为一张表，给到一个 offset，可以查询到对应 swap slot，是否在内存也有副本，如果有，副本是哪一个 page。
在 swapcache 的管理上，Linux 内核采用了与文件页 page cache 管理相似的做法，甚至底层 swapcache 的查询 API 都间接是文件的 API：
目前 Linux 内核把 swap 分区/文件的每 64MB 组织为一个 address_space，每 64MB 作为 1 个 xarray 来描述。
swap 相对文件其实是有显著区别的：
1. swap 分区/文件的数量是相对有限的，往往就是 1 个，常见的配置也很难超过 4、5 个。不像文件，可能成千上万无数个。
2. swap 的大小相对来说是固定的，可预测的。比如开机配置好了，就基本不动了。不像文件，有大有小，大则多少个 T，小则多少个 B，五花八门。
3. swap 的访问模型相对可控，针对特定的 workload 场景，有多少 swap 空间会被用到，相对来说是可预测的。
这为 swapcache 的至简化设计创造了可能性，swap table 的设计和实现诞生了。
假设一个swap分区是 2GB，我们先把这 2GB swap 空间按照 2MB 拆分为cluster：
而每个 cluster 内部则有 512 个 swap slot。
swap table 的设计理念非常简单，它为每个 cluster 给出 512 个 unsigned long 型数据，这个 unsigned long 数据可以存放 swapcache 命中的 page(现在我们或可别扭地称呼它为“folio”)的指针，或者是 shadow（用于 refault 机制），或者是 NULL。
这样，对于 64 位的 arm64， x86_64 等 arch 而言，每个 cluster 的 swap table 占据的内存正好是 4KB。
根据 swap offset，我们通过它的高位可以找到它属于哪个 cluster，而通过它的低位可以找到它对应 512 个 slot 里面的哪一个 slot：
staticinlineunsignedintswp_cluster_offset(swp_entry_tentry){returnswp_offset(entry) % SWAPFILE_CLUSTER; }
由此可见，这个检索过程是相对于 xarray 而言是更快的，相对于 xarray 原先的 O(logN)，现在可认为是 O(1)。原先 swapcache 虽然限制了每个 address_space 的大小为 64MB，但是树的深度还是可以达到 3 级的。
另外，由于一个 cluster 的 swap table 的内存都聚集在同一个 page 里面，当 swap out 密集发生在同一个 cluster 的时候，它能表现出更强的 locality 局部性，有利用减小 cache miss 等。xarray 的树形结构以及基于 slab 的内存管理方式，则更可能在多个 page 里面来回跳跃访问。
xarray 的树管理一个更广阔的范围，每个 address_space 为 64MB，这意味着，会跨越多个 cluster，64MB 的范围需要统一管理和加锁，并且 cluster 内部的访问也需要 cluster lock。而 swap table，本身不会垮 cluster，仅在一个 cluster 内部访问，只需要对 2MB 的 cluster 本身加锁。由此去掉了原先管理 xarray 树形结构的锁需求。
最后，大道至简，swap table 这种类似数组的设计思路，写出来的代码人人都能看得懂。
关于 swap table 内存占用方面的优化，在[PATCH 8/9] mm, swap: implement dynamic allocation of swap table 中，Chris 和 Kairui 实际安排了 swap table 的动态释放，在一个 cluster 里面的 512 个 slot 都没人用的时候，这个 cluster 的 swap table 可以释放。
由于 swap table 的显著优势来源于查询路径的缩短、locality 的提升、lock contention 的减小，相对 xarray 加速了 swapcache 的查询、修改等操作，属于基础设施的改善，其优势在服务器等场景会呈现较大的实用价值，对一些关键业务的吞吐量带来提升。
TCP 零拷贝发送 DMABUF
Device Memory TCP (devmem TCP)完成了 2 个目标：
通过网络发送设备 memory。底层的设备 memory 采用 dma-buf 机制；
通过网络接收设备 memory 并直接存入本地的设备 memory。
因此，它是一种 Direct-to-device 的网络方法。
我们知道 dma-buf 提供了一种本机内部设备与设备、设备与设备共享内存的方法，之前笔者已经在《)》中有论述。简单地来说，dma_buf 可以实现 buffer 在多个设备的共享，应用可以把一片底层驱动 A 的 buffer 导出到用户空间成为一个 fd，也可以把 fd 导入到底层驱动 B。当然，如果进行 mmap 得到虚拟地址，CPU 也是可以在用户空间访问到已经获得用户空间虚拟地址的底层 buffer 的。
devmem TCP 实际上把 dma-buf 的传输扩展到网络上并非本机的设备、CPU 之间了。由于是 A 机器的 dma-buf 送到 B 机器的 dma-buf，这样避免了设备的 dma-buf 和 host buffer 之间的拷贝。
跨节点的 device 到 device 的传输，在下面的一些应用场景中可能受益：
分布式训练，即在不同主机上的机器学习加速器（如GPU）之间交换数据。
分布式 raw block storage 应用与远程 SSD 传输大量数据。其中大部分数据不需要主机处理。
相关的 patchset 主要由 Google 的 Mina Almasry 完成，Linux 6.12 中支持了 rx，而 6.16 内核中，也支持了 TCP dmabuf 的 tx 路径。接收端的网卡应支持 header 的自动分离，并且支持 flow steering 、RSS，确保目标是 devmem 的网络包能流向正确的 RX queue。
调度器时间片扩展 time slice extension
想象用户态的线程 A 拿到了 spinlock，由于用户态 spinlock 并不会像内核态 spinlock 那样禁止抢占，完全有可能线程 B 抢占线程 A，线程 B 可能运行很久，而假设线程 C 需要等待线程 A 的 spinlock 释放，这个 C 的等待可能是非常长的。
如果我们提供一个机制，比如线程 A 拿到了 spinlock，在 critical section 里面执行的过程中，若发生时间片用完或者其他什么事情要抢占 A，调度器可以扩展一点点时间片给 A，比如 50 微妙内让 A 不被抢占，则线程 A 大概率可以执行完 critical section，从而规避一系列问题。而具体扩展时间片的长度则可由新增的 rseq_slice_extension_nsec 这个 sysctl 决定。
用户空间线程通过 prctl 显式地告诉内核，它需要时间片扩展：
有一个 per-cpu 的 Restartable sequences（简称rseq）供用户态和内核态交互，需要时间片扩展的一个典型的用户态伪代码如下：
如果线程通过 prctl 启用了该机制，就可以把 rseq::slice_ctrl::request 设为 1 来请求延长当前时间片。当线程被中断且内核因此产生重新调度请求时，内核看到了用户态设置了 rseq::slice_ctrl::request =1，它可能选择不立即把线程换下 CPU，而是批准一次 rseq_slice_extension_nsec 时间片扩展并直接返回用户态继续执行。
当内核同意时间片扩展时，会把 rseq::slice_ctrl::request 清零，并将 rseq::slice_ctrl::granted 置为 1，表示扩展已批准；如果在扩展之后线程仍然被resched（被换下 CPU），内核会再把 granted 位清零，用来通知用户态这次扩展已经结束或失效。
基于 RSEQ 的时间片扩展工作，主要由 Thomas Gleixner 和 Peter Zijlstra 完成。
multi-kernel
Cong Wang 在 LKML 发送了一个 RFC 序列，支持 multi-kernel。multi-kernel 与容器、hypervisor 都有本质不同,它在同一台机器上并行运行多个 Linux kernel，每个 kernel 独占一部分硬件，并通过消息通信协作。
在 Cong Wang 建议的方法中，host kernel 管理 spawn kernel。
Host kernel 负责：硬件资源管理、创建 / 销毁子 kernel、跨 kernel 协调。Spawn kernel 负责跑应用、具备独立调度 / 内存 / IO 并与其他 kernel 隔离。Cong Wang 的 multi-kernel 实现可以概括为：
用 kexec 在同机启动多个 Linux
用 CPU / 内存 / IO 硬件分区做隔离
用 IPI + 共享内存通信
用 hotplug + DT overlay 动态调资源
用硬件 queue 切分 IO
每 workload 跑定制 kernel
这个 multi-kernel 方案未来会走向何方、能否在 Linux 内核上游社区引起足够关注和投入，都会是很值得观察的看点。
io_uring 的网络零拷贝收包
由 Pavel Begunkov 和 David Wei 完成的工作，正式合入 Linux 内核 6.15，为 io_uring 增加了零拷贝接收（zero-copy receive）支持，使数据能够直接批量、快速地接收并写入应用程序内存，而无需再从内核内存中拷贝一份。
io_uring 的零拷贝与 DPDK 有很大不同，DPDK 完全 bypass 了内核，而 io_uring 这种内核为 userspace 提供的 async I/O 模式，则仍然重用了内核的网络机制，如下图，借鉴硬件的支持，payload 被硬件直接 DMA 到 userspace 的 buffers。
io_uring 提供了一种“混合旁路（hybrid bypass）”机制：在保持与 Linux 内核体系紧密集成的同时，实现了显著的性能提升。相比 DPDK 这种完全旁路（full bypass）方案，它在使用上更加便捷，对现有系统的侵入性也更低。
它的整个工作流程如下：
在 io_uring中，用户和内核通过 2 个 queue 交互：SQ（Submission Queue）、CQ（Completion Queue）。
由于 DMA 要直接往 userspace 的 buffers 里面传输数据，所以 buffer 需要在内核 pin 住，相关 API 是：io_uring_register_buffers。
与前面的 devmem TCP 相似，该机制也依赖于硬件的报文头/数据分离（header/data split）、流量引导（flow steering）以及 RSS（接收端扩展），以确保数据包头部保留在内核内存中，而只有目标流量才会被导向配置为零拷贝的硬件接收队列。
io_uring dmabuf 读写支持
这个 patchset 试图让存储设备（如 NVMe）可以直接 DMA 到 dmabuf 所代表的内存，而不是走用户页缓存 / copy 路径。
用户态发起：
即：
提供 dmabuf fd
提供目标 file fd（如 nvme block）
发起读：
注意这套能力不是给通用文件 I/O 准备的，而是给高性能数据管线 / 设备直通 pipeline 用的，不是 ext4 / f2fs 等文件读写。
该 patchset 把 dmabuf 封装成一种可被 block 层提交和 DMA 的 buffer 类型，让存储设备可以直接对 dmabuf 做 DMA。主要实现原理（4 步）:
A.注册：dmabuf → dma_token
用户用 dmabuf fd 注册 io_uring buffer 时：
dma_buf_get
dma_buf_attach(target_device)
dma_buf_map_attachment
→ stable
然后封装成一个内部对象：dma_token，它代表一块可 DMA 的共享内存。
B. 提交 IO：新 iterator 类型
新增一种 buffer 迭代器：ITER_DMA_TOKEN
提交 read/write 时：
SQE → dma_token → iov_iter
C. 构建 bio / request
block 层改造后可以：
bio → dma_token → sg_table
不再依赖 page，而是直接用 dmabuf 的 scatter-gather 表。
D. Driver DMA
以 NVMe 为例：
sg_table → PRP / SGL → device DMA → dmabuf
实现存储设备直接 DMA 到 dmabuf 内存。
dmem cgroup
在较早的内核中，cgroup 已经可以管理普通系统内存（RSS、swap 等），但缺少针对 GPU / 加速器设备内存的统一计量与限制机制。
dmem cgroup 是用来对“设备私有内存（device memory）”做资源隔离与计量的 cgroup 控制器。它管的不是普通 DRAM，而是 GPU、accelerator 和其他的 device 本地内存。dmem cgroup 目的在于：
让 cgroup 能统计设备内存使用量；
能针对这些内存设置 min/low/max 限制；
能在资源过度使用时做 eviction（回收/驱逐）
在 Linux 6.14 中，DMEM cgroup 支持已经集成到 Intel Xe 内核图形驱动中，用于根据 cgroup 层级限制显存（vRAM）的使用。这个用于显存内存计数的 DMEM cgroup 代码，也可以“轻松地”被其他依赖 TTM（Translation Table Maps）进行内存管理的内核图形驱动复用。
dmem 的 cgroup 接口如下：
dmem.current：当前 cgroup 使用的 device memory 字节数；
dmem.max, dmem.min, dmem.low： nested-keyed（支持层级键值），用于配置不同 cgroup 的内存资源限制；
dmem.capacity：显示该内存区域的最大容量，仅存在于 root。
dmem 的整个实现原理如下：
作者简介
宋宝华，经典读书《Linux设备驱动开发详解》作者。Linux 主线内核dma-mapping benchmark、SWAP、THP 的维护者或审核者，累计给 Linux 主线内核贡献数百个补丁。在 Linux 调度器、内存管理、ARM arch、DMA、中断、驱动等领域有广泛的贡献，是 SCHED_CLUSTER、PER_NUMA CMA、zswap 硬件压缩解压、ARM64 TLB batch unmap、swap entries 批量 unmap、mTHP swap-in、madvise PER_VMA lock 等特性的 author 或 co-author。
参考文献：
[1]slab sheaves和barns
[2]sched-ext sub-schedulers:
[3]代理执行Proxy Execution:
[5]scheduler时间片扩展：
[6]tcp dmabuf tx零拷贝：
[7] io_uring zero_copy rx:
[8] io_uring file->dmabuf:
[9]dmem cgroup:
[10]swap table: