引言
在大规模数据中心和云计算运维中，如何"不中断业务更换宿主机内核"一直是顶级技术难题。传统的内核升级需要重启服务器，这意味着硬件自检（BIOS/UEFI）会耗费数分钟，且所有运行中的虚拟机（VM）和业务都会被迫中断。
为了解决这一痛点，Linux 内核近年来在实时更新（Live Update）领域投入了大量精力，逐步构建起了由 kexec 、kexec 移交（kexec handover） 和 live update orchestrator（实时更新编排器） 组成的核心技术链条。
然而，这项工作目前尚未彻底完成。在 2026 年的 Linux 存储、文件系统、内存管理与 BPF 峰会（LSFMM+BPF）上，Pratyush Yadav 主持了一场内存管理分轨会议，议题围绕一个核心突破点展开：如何在实时更新过程中，增加保留由 hugetlbfs（大页文件系统）提供的内存的能力。
核心技术底座：三者的协同演进
要理解这一全新突破，首先需要明确 Linux 实时更新技术链条中的三个关键组件及其分工：
-
kexec（快速内核引导）：
这是 Linux 内核中早已存在的一个系统调用和工具。它允许直接从当前运行的内核跳转并引导 到一个新的内核，完全绕过硬件自检（BIOS/UEFI）阶段。虽然 kexec 速度极快（仅需几秒），但它在跳转时默认会清空整片物理内存，导致正在运行的虚拟机和容器全部中断。
-
kexec handover（内存状态移交）：
为了解决内存被清空的问题，内核引入了移交机制。这是一套内核内部的机制，允许旧内核在退出时，将特定的内存区域（Memory Regions）标记为"保留"。新内核启动后会绕过清单上的区域，并把这些保留的内存重新恢复给对应的进程。该接口纯粹位于内核层，没有提供直接给普通用户使用的 API。
-
live update orchestrator（实时更新编排器）：
这是连接"用户空间（User Space）"与"内核空间（Kernel Space）"的桥梁和指挥官。它为管理员提供了用户空间接口，用来扫描、识别、决定哪些资源需要保留，并指挥内核在切换后如何恢复它们。
峰会直击：迈向高效的 hugetlbfs 内存保留
在 2026 年的峰会上，Pratyush Yadav 展开了关于该项技术最新进展的分享。
当前的局限性与 Yadav 的目标
Yadav 首先介绍道，实时更新的核心应用场景是在不干扰运行在该主机内核之上的虚拟机（VM）的情况下，替换运行中系统的宿主机内核。kexec 移交机制负责将特定的内存区域标记为"在内核更换期间需要保留"的区域；这是一个内核内部的接口，没有提供用户空间 API。一旦内存被成功标记，系统就会调用 kexec_load() 系统调用来引导新内核，之后这些保留的内存将被重新恢复给它原本所属的进程。而实时更新编排器则为该功能提供了用户空间接口，允许用户标记需要保留的资源，并在新内核上对其进行恢复。
kexec 移交和实时更新编排器在 Linux 6.19 开发周期中被合并，但当时对于基于内存的文件系统中文件保留的支持还非常有限。它只能处理由共享内存支持的 memfd（通过 memfd_create() 创建的匿名文件），几乎无法支持其他类型。虽然该功能可以用来保留虚拟机的内存内容，但在 memfd 中运行虚拟机相对来说效率较低。如果将虚拟机放置在来自 hugetlbfs 子系统的少量巨页（Huge Pages，例如 1GB 规格的巨页）中，其运行效率会高得多，然而这类内存目前在实时更新后还无法存活。
Yadav 的目标是让这些虚拟机（以及它们关联的内存）能够顺利度过实时更新过程。最好能够通过一种特殊的 memfd 来获取 hugetlbfs 页面，这样就不需要再去挂载 hugetlbfs 本身。其目的是尽量减少需要保留的状态数量；因为所有被保留的内容都会变成内核 ABI（应用二进制接口）的一部分，所以保留的东西越少越好。同时，他也致力于尽量减少对 hugetlbfs 本身的代码改动。
实现机制与工作原理
该功能的工作流程如下：
-
冻结（Freezing）： 首先冻结需要保留的巨页内容，以确保在更新过程中数据更改不会丢失。实现这一点有两种方法：
-
第一种方法是向相关的 hugetlbfs 索引节点（inodes）添加一个标志，并在即将发生数据修改时检查该标志。共享内存文件系统（tmpfs/shmem）就是采用这种方式。此外，相关的内存将被固定（pinned），以防止在更新期间发生内存迁移（migration）或内存紧缩（compaction）。这一方案虽然可行，但被部分开发人员认为有点像"临时补丁（hack）"。
-
第二种替代方案是通过引入一个新的地址空间标志（address-space flag），让文件映射（filemap）代码感知到"冻结"状态；同样，该标志会在允许修改前被检查。为了让这一方案正确运行，内核需要处理各种细节，这意味着虚拟文件系统（VFS）层必须能够感知到整个冻结过程。
-
-
记录元数据： 在页面被冻结后，系统会记录每个页面的部分元数据（包括其大小和位置）。随后，被冻结的页面和这些元数据都会被标记为"保留"。
-
内核更新： 此时，更新过程可以正常推进。
-
在新内核中恢复： 一旦新内核开始运行，系统会创建一个新的基于 hugetlbfs 的 memfd，并将其中的每个巨页重新投入使用，同时更新相应的 hugetlbfs 状态。接着系统会完成针对已分配内存的控制组（cgroup）计费，并将新页面添加到页面缓存（page cache）中。至此，从内存保留的角度来看，更新过程大功告成。
潜在的冲突与挑战
Yadav 指出，在巨页分配 方面存在一个复杂的并发症。Hugetlbfs 的工作原理是在启动过程中预先分配固定数量的巨页。而在恢复基于 hugetlbfs 的虚拟机时，系统也会去分配必要的巨页。在原内核中，这些页面是从 hugetlbfs 中分配的；但在新内核中，它们目前是被独立分配的。这可能会导致巨页整体上的超额分配（over-allocation）。
解决方案： 在新内核引导时统计被保留的巨页数量，然后相应地减少 hugetlbfs 预分配的页面数量。
另一个尚未解决的问题是该功能与连续内存分配器（CMA）的交互。如果原始的巨页是从 CMA 中获取的，那么在更新后，这些新页面需要被重新插回 CMA 中，但 CMA 目前并没有提供任何扩展其内存区域（memory zone）的方法。因此，在当前的补丁集中，如果启用了实时更新，系统将直接禁用 hugetlbfs 与 CMA 的配合使用。虽然未来某天可能会实现保留 CMA 的状态，但这在当前的开发版本中还无法做到。
现状总结与未来展望
Yadav 在会议最后对当前的开发进展进行了总结。他提到，一份 RFC（征求意见稿）补丁集已于 2025 年 12 月发布。在推进这项工作的过程中，他发现了 kexec 移交机制中存在的一系列问题，这需要对基础设施进行大量的修复调整。在对收到的反馈进行逐一回应后，他很快就会提交一份更新后的补丁集。
在问答环节，唯一的提问来自 Mike Rapoport，他询问"让 CMA 页面变得可移动（movable）是否有助于将其与 kexec 移交进行整合"。Yadav 回应称，这样的改动极有可能会破坏现有的稳定性，而且可能并不会带来太大的实质性帮助。
随着 hugetlbfs 内存保留补丁的逐步完善，Linux 实时更新（Live Update）技术的最后一块拼图正被补齐。届时，公有云及企业级数据中心将能够在真正意义上实现"高性能虚拟机毫无察觉"的宿主机内核无缝升级。
