继《》、《》、《》之后，知名 Linux 内核一线开发者，经典书籍《Linux 设备驱动开发详解》作者宋宝华老师又给大家带来了 2025 年 Linux 内核开发中，十个最典型的patchset，为大家呈现干货满满的硬核技术年货。
作者 | 宋宝华 责编 | 张红月
出品 | CSDN（ID：CSDNnews）
从明天起，做一个幸福的人。喂马，劈柴，周游世界。从明天起，关心粮食和蔬菜。我有一所房子，面朝大海，春暖花开。 ——海子《面朝大海，春暖花开》
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//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：
}
由此可见，这个检索过程是相对于 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() 显式地告诉内核，它需要时间片扩展：
prctl(PR_RSEQ_SLICE_EXTENSION, PR_RSEQ_SLICE_EXTENSION_SET, + PR_RSEQ_SLICE_EXT_ENABLE, 0, 0);
有一个 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 路径。
用户态发起：
{ dma_buf_fd, file_fd });即：
提供 dmabuf fd
提供目标 file fd（如 nvme block）
发起读：
io_uring_prep_read_fixed(..., reg_buf_idx);
注意这套能力不是给通用文件 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
让 block 层识别这是 dmabuf，而不是用户页。
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
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]代理执行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时间片扩展：
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 与奇点智能研究院联合主办「2026 奇点智能技术大会」将在上海隆重召开，大会聚焦 Agent 系统、世界模型、AI 原生研发等 12 大前沿专题，为你绘制通往未来的认知地图。
成为时代的见证者，更要成为时代的先行者。
奇点智能技术大会上海站，我们不见不散！
华林优配APP提示：文章来自网络，不代表本站观点。
