LWN：6.1 合并窗口第二部分！

关注

转载最新推荐文章于 2026-03-08 05:36:55 发布 563 阅读 AI 写同款· GEO 优化 ›

Linux内存管理专题 - 第14章：内存回收与LRU机制基本概念当系统内存不足时触发回收机制主要回收目标：用户进程页、内核缓存、slab对象两种回收方式：直接回收（同步）后台回收（kswapd守护进程异步进行）回收策略// 内核典型回收路径。阅读详情

关注了就能看到更多这么棒的文章哦～

The rest of the 6.1 merge window

By Jonathan Corbet
October 17, 2022
DeepL assisted translation
https://lwn.net/Articles/910608/

Linus Torvalds 于 10 月 16 日发布了 6.1-rc1，并关闭了 6.1 合并窗口；此时，有 11537 个 non-merge changeset 已经被合入 mainline 仓库。这比 6.0 合并窗口期间的 13543 个 changeset 要少得多，但数量并不是一个全面的指标，在这个版本中有了相当多的重大改动。其中有不少属于是在我们第一次 6.1 合并窗口的总结之后合入的近 5,800 个 changeset；请继续阅读来了解这次合并窗口的后半部分中完成的一些工作。

Architecture-specific

Loongarch 架构中支持了 perf event、kexec、kdump 和 BPF 即时编译（just-in-time）的支持。
EFI 系统上的内核现在可以用跟体系架构无关的方式来对自己解压和启动。

Core kernel

新增了一个 io_uring mode（要使用的话，只要在设置 ring 的时候使用 IORING_SETUP_DEFER_TASKRUN 标志即可），这会使得 ring 相关工作的执行被推迟，直到应用程序希望它完成的时候。这样延期一下可以有助于让这些工作批量进行，并防止在合适的时间点产生应用程序抢占而引起的延迟问题。在相关 commit 中有一些介绍。
process-ID cgroup controller 现在可以记住所使用的 PID 最大数量，这可以用来帮助决定相应的限制；这个数值在一个名为 peak 的虚拟文件中提供了出来（be exported）。
用户空间进程现在可以请求将一系列 page "collapsed（折叠）" 成 transparent huge pages。当然，这会导致这些 huge page 不那么透明了，但它也可以允许用户空间来控制是否要做，以及什么时候来做这个动作。
合并了/dev/userfaultfd patch，这就给系统管理员提供了一种方法，可以用文件系统的访问权限来授权访问 userfaultfd() 功能。
memory-tiering，就是对具有不同性能特征的多种内存进行管理；通常情况下，人们希望最常用的 page 能驻留在速度最快的内存中，而不太经常使用（但仍然有用）的 page 可以放在较慢的 RAM 中。在 LWN 文章中介绍过的两个内存分层 patch set 已经合并到 6.1 中。"hot page selection" 机制改进了在较慢的 RAM 中的 busy page 的检测，从而方便把它们提高到更快的内存里。同时，"demotion-order （降级顺序） " patch set 正式确定了内核对 memory tier 的定义以及它们的相对性能的概念，允许对这些 tier 更好地进行管理。
multi-generational LRU 代码已经合并了。这项工作用了一个 multi-stage structure 来取代了内核的 two-queue、least-recently-used 机制，据说它能更好地识别哪些内存 page 是在被实际使用。并且提供了一个 "kill switch"，可以用来关闭掉新的机制，比如在某个特定的系统上由于它导致了问题的话。相关的 administrative guide 中有一些信息关于如何控制这个功能，而相应的 design documentation 则介绍了它的工作机制。
关于 multi-generational LRU 以及 tiering 机制的相互：LRU 主要处理每个 zone（同一 node 上每一个由相同类型的物理连续内存组成的区域）内的内存管理，而 tiering 则是关于 zone 之间的 page 的移动。
maple tree 数据结构也被合并了。这个功能可以更有效地取代红黑树，希望它也能在未来帮助实现 range locking 功能。已经把一些非常核心的内存管理子系统都被转换成了 maple tree 方式；幸运的话，用户唯一能感受到的变化就是性能发生了提升。
现在可以在 cgroup 级别来跟踪 pressure-stall 信息。启用这种跟踪机制可能会导致显著的性能损失；相关 commit 中有更多的信息。

Filesystems and block I/O

对 Btrfs 进行了一些修改，提供了显著的性能提升，包括对 FIEMAP ioctl() 的速度给出了 "数量级的提升"。
Btrfs 现在支持使用 io_uring 的 buffered write。
Btrfs 的 "send" 操作已经支持了使用了 fs-verity 保护的文件。
用户空间的文件系统 (FUSE) 子系统支持了使用 O_TMPFILE 创建临时文件。

Hardware support

Clock。联发科 MT6795 和 MT8365 时钟控制器、高通 MSM8909 和 SM6375 全局时钟控制器、高通 SM6115 和 SM8450 显示时钟控制器、高通 SC8280XP 图形时钟控制器、Rockchip RV1126 时钟控制器、展讯 UMS512 时钟和瑞萨 Versaclock 7 时钟控制器。
GPIO and pin control。赛普拉斯 Cy8C95x0 pinctrl/gpio I2C 扩展器，高通 SC8280XP 和 SM8450 LPASS LPI 引脚控制器，以及联发科 MT8188 引脚控制器。
Industrial I/O。Liteon LTRF216A 光传感器、Richtek RTQ6056 电流和功率监视器、MEMSensing 数字 3 轴加速度计、Maxim max11205 模数转换器和 Bosch Sensortec BNO05 IMU。
Input。IBM 操作面板，Richtek RT5120 PMIC 电源键，以及 Pine64 PinePhone 键盘。
Media。恩智浦 i.MX DW100 露光器和联发科的媒体数据路径接口。
Miscellaneous。Synopsys DWC AHCI SATA 控制器、Microchip LAN9662 OTP 控制器、Microchip PolarFire SoC 复位控制器、Aspeed HACE 加密引擎和 Exar 看门狗定时器。
Multi-function device。联发科 MT6370 电源管理 IC Richtek RT5120 电源管理 IC，以及 Rockchip RK817 PMIC 电池充电器。
USB。凌阳 SP7021 USB 2.0 PHYs 和联发科 MT6370 Type-C 控制器。

Miscellaneous

perf 工具跟平常一样，又得到了一长串的改进，其中包括对 AMD 处理器的支持的改善；相关的 merge message 中包含了摘要介绍。

Security-related

早在 5.6 版本中，对 O_NONBLOCK 的支持就被（意外地）从/dev/random 中移除了。最终有人注意到并抱怨了出来，因此该支持将在 6.1 版本中被 revert 掉（估计还需要对稳定版 kernel 进行更新）。

Internal kernel changes

在各种 slab 分配器代码中持续进行重构，从而增加它们之间可以公用的代码的数量。一个可能被注意到的行为上的改动是，SLAB 现在将直接从 page allocator 中获得大块的分配 buffer，而不需要自己维护一个单独的 cache 缓存了。
这项工作的长期目标是最终能够移除 SLAB 和 SLOB 分配器，但这仍然是一个非常遥远的事情。
出现了一个接口，可以展示由于 kmalloc()对分配大小进行四舍五入而导致了多少内存浪费；相关 commit 中描述了如何使用。
内核构建系统（kernel build system）现在最少也需要 GNU Make 版本 3.82 了。
如果内核子系统对某块 memory 既设置了可写属性又设置了可执行属性，那么现在 x86 架构代码会发出 warning。最初的计划是完全禁止这种 mapping 方式，但由于一些比较晚才发现的意外情况，所以这个计划被推迟了。
内存管理功能仍在继续切换到 folio，这个版本中大多数改动都是集中在 swap 部分。
在 LWN 文章中简要介绍过的 kernel memory sanitizer（KMSAN）已经被合并了。KMSAN 专注于检测内核中使用了未初始化的内存的地方；相关的 documentation patch 描述了如何使用。
checkpatch.pl 脚本现在会抱怨那些使用了已废弃的 kmap() 和 kmap_atomic() 函数的代码；现在代码应该使用 kmap_local_page() 来代替了。
在内核代码如何获得随机数方面，已经有了相当多的混乱信息；在这个 merge message 中描述了应该如何最好地使用随机数相关的内部 API。