继《2022 Linux 内核十大技术革新功能》、《熠熠生辉 | 2023 Linux 内核十大技术革新功能》、《2024 年 Linux 内核十大技术革新盘点》之后知名 Linux 内核一线开发者经典书籍《Linux 设备驱动开发详解》作者宋宝华老师又给大家带来了 2025 年 Linux 内核开发中十个最典型的patchset为大家呈现干货满满的硬核技术年货。作者 | 宋宝华 责编 | 张红月出品 | CSDNIDCSDNnews从明天起做一个幸福的人。喂马劈柴周游世界。从明天起关心粮食和蔬菜。我有一所房子面朝大海春暖花开。——海子《面朝大海春暖花开》2026 农历新年的钟声即将敲响在这全球共庆的跨年时刻Linux 内核年度十大技术创新盘点如约而至。回望过去的一年平凡的日子里夹杂着些许苦涩与无奈。每一个渺小的个体无论心中藏着怎样的悲伤或喜悦都让它随风而去吧。新的一年里纵然现实仍有诸多束缚也愿诸君心底已然面朝大海春暖花开。过去的一年内核开发者们废寝忘食地沉浸在代码的纯粹世界中不断提交patch推动 Linux 内核前行。本文将盘点其中最具代表性的十个 patchset:1slab per-CPU cache机制Sheaves(一捆)和barns(谷仓)2sched_ext: cgroup sub-scheduler支持3代理执行proxy-execution以解决优先级翻转4swap table替代xarray5TCP零拷贝发送DMABUF6调度器时间片扩展time slice extension7multi-kernel8io_uring的网络零拷贝收包9io_uring dmabuf读写支持10dmem 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()来触发子调度器的 dispatchchild 再选具体 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 替代 xarrayswap 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。static int swap_table_alloc_table(struct swap_cluster_info *ci){ WARN_ON(ci-table); ci-table kzalloc(sizeof(unsigned long) * SWAPFILE_CLUSTER, GFP_KERNEL); if (!ci-table) return -ENOMEM; return 0;}这样对于 64 位的 arm64 x86_64 等 arch 而言每个 cluster 的 swap table 占据的内存正好是 4KB。根据 swap offset我们通过它的高位可以找到它属于哪个 cluster而通过它的低位可以找到它对应 512 个 slot 里面的哪一个 slotstatic inline struct swap_cluster_info *swp_cluster(swp_entry_t entry){ return swp_offset_cluster(swp_info(entry), swp_offset(entry));} static inline unsigned int swp_cluster_offset(swp_entry_t entry){ return swp_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这意味着会跨越多个 cluster64MB 的范围需要统一管理和加锁并且 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 零拷贝发送 DMABUFDevice Memory TCP (devmem TCP)完成了 2 个目标通过网络发送设备 memory。底层的设备 memory 采用 dma-buf 机制通过网络接收设备 memory 并直接存入本地的设备 memory。因此它是一种 Direct-to-device 的网络方法。我们知道 dma-buf 提供了一种本机内部设备与设备、设备与设备共享内存的方法之前笔者已经在《世上最好的共享内存(Linux 共享内存最透彻的一篇)》中有论述。简单地来说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-kernelCong 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 交互SQSubmission Queue、CQCompletion 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 路径。用户态发起io_uring_update_buffer(ring, idx, { 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 / requestblock 层改造后可以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 代码也可以“轻松地”被其他依赖 TTMTranslation 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和barnshttps://lore.kernel.org/linux-mm/20260123-sheaves-for-all-v4-0-041323d506f7suse.cz/[2]sched-ext sub-schedulers:https://lore.kernel.org/lkml/20260121231140.832332-1-tjkernel.org/[3]代理执行Proxy Execution:https://lwn.net/ml/all/20250712033407.2383110-1-jstultzgoogle.com/https://lwn.net/ml/all/20250722070600.3267819-1-jstultzgoogle.com/[5]scheduler时间片扩展https://lore.kernel.org/lkml/20251215155615.870031952linutronix.de/[6]tcp dmabuf tx零拷贝https://lore.kernel.org/netdev/20250508004830.4100853-1-almasryminagoogle.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.silencegmail.com/[9]dmem cgroup:https://lore.kernel.org/lkml/20241204134410.1161769-1-devlankhorst.se/[10]swap table:https://lore.kernel.org/linux-mm/20250822192023.13477-1-ryncsngmail.com/https://lore.kernel.org/linux-mm/20250514201729.48420-25-ryncsngmail.com/