在虚拟化与云原生架构中宿主机内核的 Live Update热升级是实现无感运维的关键技术。Linux 内核的KHO (Kernel Highway Overpass)机制允许系统在跨内核重启Re-exec时保留关键内存数据Preserved Memory从而实现虚拟机的零中断热升级。然而当宿主机将绝大部分物理内存配置为1GiB 巨页Gigantic Huge Pages供 VM 使用时KHO 遭遇了严重的架构瓶颈巨页分配挤爆了 KHO 的早期引导空间Scratch Area导致热升级流程频繁崩溃。近期 upstream 出现的一套重构补丁集通过引入Extended Scratch扩展 Scratch 区域与Radix 树摘要算法彻底解耦了巨页与 Scratch 空间的死锁逻辑。一、 根因剖析为什么 1GiB 巨页会“算爆” KHO ScratchKHO 在 Early Boot 阶段依赖一个独立的预留内存区——Scratch 区域。它的核心架构约束是仅供新内核解压与初始化使用绝对不能包含任何跨重启保留的数据Preserved Memory。在旧有的实现中存在一个致命的逻辑闭环【旧机制的崩溃死锁】 Early Boot Memblock 分配 │ ▼ ┌───────────────────┐ │ KHO Scratch 区域 │ ◄─── 巨页被迫强行挤入 └─────────┬─────────┘ │ ┌─────────────────────────┴─────────────────────────┐ ▼ ▼ [ 衍生问题 1: 容量算爆 ] [ 衍生问题 2: 属性违例 ] 巨页被打上 RSRV_KERN 标签, 巨页属于 Preserved Memory, 引发 Scratch Scale 乘法暴胀 (超出物理内存上限) 打破了 Scratch 不含保留数据的底线分配路径交织在 Early Boot 阶段所有由memblock申请的内存包括 VM 巨页全都被强制落入初始 Scratch 区域内。容量计算暴胀Accounting Breakdownmemblock默认将巨页标记为内核预留内存RSRV_KERN。KHO 会根据RSRV_KERN的大小乘以缩放系数scratch_scale如 1.5来推算下一个内核所需的 Scratch 空间Scratch Size Total(RSRV_KERN) * scratch_scale若宿主机配置了 800 GB 巨页SRV_KERN 就会被误统计为 800 GB乘上系数后 KHO 试图预留1.2 TB的 Scratch 空间导致系统直接因 OOM 崩溃。架构红线违例VM 巨页属于需要在 KHO 重启间保留的 Preserved Memory。将其存放在 Scratch 区域中会导致新内核在覆盖 Scratch 时面临破坏 VM 内存的风险。二、 核心破局Patchset 的“分流与扩展”架构这套 Patchset 的本质思路非常清晰解除巨页对 Scratch 的绑架让巨页在 Scratch 外部的安全空闲块中进行分配。【新机制的分流架构】 Early Boot Memblock 分配 │ ┌────────────────────────┴────────────────────────┐ ▼ ▼ (常规内核引导内存) (VM 巨页分配) │ │ ▼ ▼ ┌──────────────────┐ ┌─────────────────────┐ │ Initial Scratch │ (仅存内核代码/临时结构) │ Extended Scratch │ (由 Digest Radix 树 └──────────────────┘ └─────────────────────┘ 动态发现的 1G 空闲块)三、 补丁集的关键技术实现1. 专属分配通道memblock_alloc_hugetlb()Patchset 为巨页打造了专属接口memblock_alloc_hugetlb()在代码层做出硬性隔离主动绕开 Scratch在memblock_find_in_range_node()寻找空闲内存段时若发现候选区间落在 KHO 初始 Scratch 内直接跳过Skip。独立类型标记将巨页标为MEMBLOCK_RSRV_HUGETLB不再混入通用内核预留内存RSRV_KERN。保护镜像内存Mirrored Memory明确禁止巨页占用昂贵的硬件镜像内存将珍贵资源留给核心内核结构。2. 算法创新Radix 树摘要Digest Radix Tree与动态扩展既然巨页不能在初始 Scratch 中分配Early Boot 阶段去哪里找足够的物理内存Patchset 引入了Extended Scratch机制其核心是一套巧妙的 Radix 树转换算法[ 原始 Preserved Radix Tree ] ──(单次遍历)──► [ Digest Radix Tree (1GiB 粒度) ] (包含分散的 4KB, 2MB 保留页) (按 1GiB 物理块汇总的位图树) │ ▼ [ 遍历 Digest 树找到空隙 ] │ ▼ [ 标记为 Extended Scratch ]单次遍历与摘要Digest在启动极早期遍历记录跨重启保留内存的原始kho_radix_tree并将其“摘要Digest”压缩建出另一棵临时的 Digest Radix Tree。1GiB 粒度对齐与找空隙Digest 树以1 GiBKHO_SCRATCH_EXT_BLKSIZE为粒度规整物理内存。树中相邻两个被占用的 Key 之间的空白区间即代表这几吉字节的物理内存绝对没有任何保留页。低开销与用完即销毁对于小于 32 TiB 的服务器整个 Digest 树仅需6 个内存页KHO_TREE_MAX_DEPTH 6。在向memblock注册完成 Extended Scratch 后系统会立即调用新引入的kho_radix_destroy_tree()彻底销毁这棵临时树零运行时内存残留。3. 容量计算公式的精确闭环在将巨页打上RSRV_HUGETLB标记后Patchset 引入memblock_reserved_hugetlb_size()并将 KHO Scratch 的计算公式修正为Scratch Size (Total(RSRV_KERN) - Total(RSRV\_HUGETLB)) * scratch_scale通过显式扣除巨页占用的内存真实反映内核自身的内存消耗如 20 GB彻底消除了计算暴胀问题。4. 基础设施与 Pageblock 迁移类型重构为了支持 Extended Scratch 与常规内存区域合并Merge后的属性精确划定早期分配器支持新增kho_radix_alloc_node()在slab_is_available()未就绪的极早期自动降级使用memblock申请 Radix 树节点。Pageblock 粒度评估废弃了以往对连续 range 整体查询迁移类型的逻辑改在memmap_init()阶段逐个 Pageblock如 2MB/4MB 粒度调用kho_scratch_overlap()解决了内存块合并引起的 Migration Type 属性错乱。四、 实测性能与架构意义在 64GB 内存、预分配 50 个 1GiB 巨页的 QEMU KVM 压测环境中该补丁集的表现极为出色轻度保留场景含 2 个 1M memfd仅需47 微秒$\mu s$即可完成 57GB Extended Scratch 空间的扫描与扩展。重度碎片化场景超 50 万项 4KB 页保留在极度碎片化的情况下扫描并拓展 52GB 空间仅耗时22.5 毫秒$ms$。总结这套补丁集通过memblock_alloc_hugetlb()隔离、Digest Radix 树动态发现和计算公式扣减三位一体的改动彻底打破了“巨页分配”与“Scratch 隔离”之间的矛盾为云厂商在大内存宿主机上部署 KHO Live Update 扫清了关键的架构障碍。