从明天起，做一个幸福的人。喂马，劈柴，周游世界。从明天起，关心粮食和蔬菜。我有一所房子，面朝大海，春暖花开。

——海子《面朝大海，春暖花开》

过去的一年，内核开发者们废寝忘食地沉浸在代码的纯粹世界中，不断提交patch，推动 Linux 内核前行。

本文将盘点其中最具代表性的十个 patchset: 

下面一一展开描述。

内存管理的 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 以解决优先级翻转

staticintswap_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;}

static inline struct swap_cluster_info *swp_cluster(swp_entry_t entry){    return swp_offset_cluster(swp_info(entry), swp_offset(entry));}staticinlineunsignedintswp_cluster_offset(swp_entry_t entry){    return swp_offset(entry) % SWAPFILE_CLUSTER;}

Device 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。

如果我们提供一个机制，比如线程 A 拿到了 spinlock，在 critical section 里面执行的过程中，若发生时间片用完或者其他什么事情要抢占 A，调度器可以扩展一点点时间片给 A，比如 50 微妙内让 A 不被抢占，则线程 A 大概率可以执行完 critical section，从而规避一系列问题。而具体扩展时间片的长度则可由新增的 rseq_slice_extension_nsec 这个 sysctl 决定。

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 实现可以概括为：

1. 用 kexec 在同机启动多个 Linux

2. 用 CPU / 内存 / IO 硬件分区做隔离

3. 用 IPI + 共享内存通信

4. 用 hotplug + DT overlay 动态调资源

5. 用硬件 queue 切分 IO

6. 每 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 路径。

用户态发起：

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 / 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 的整个实现原理如下：

[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/