Firecracker 如何配置 huge_pages 用大页支撑 microVM 内存

Firecracker 如何配置 huge_pages 用大页支撑 microVM 内存

【免费下载链接】firecrackerSecure and fast microVMs for serverless computing.项目地址: https://gitcode.com/GitHub_Trending/fi/firecracker

当你希望 microVM 的 guest 内存使用大页（transparent huge pages 或 2MB hugetlbfs 页）来支撑，而不是默认的 4K 页时，需要配置/machine-config的huge_pages字段。该字段接受三个取值（见 docs/hugepages.md 与 API 定义 firecracker.yaml）：

配置只能在 boot 之前完成：PUT/PATCH /machine-config都是 pre-boot 操作，必须在InstanceStart之前下发。

准备工作

1. Firecracker 进程已带 API socket 启动。按 docs/getting-started.md 的方式启动，例如：

   API_SOCKET="/tmp/firecracker.socket" sudo rm -f "$API_SOCKET" sudo ./firecracker --api-sock "${API_SOCKET}" --enable-pci

   之后所有配置都通过curl --unix-socket发送到http://localhost下对应路径。发送 API 请求的 curl 与运行 Firecracker 的用户权限要一致（都用 sudo 或都不带 sudo）。

2. 选择Transparent时确认宿主机的 THP 设置。检查方法（来自 test_huge_pages.py 的集成测试）：

   cat /sys/kernel/mm/transparent_hugepage/enabled

   输出形如always [madvise] never，方括号内为当前生效项。测试要求该值为madvise或always，否则 THP 无法生效。另外注意：即使传统 THP 在 x86_64 上是 2MB（PMD 大小），实际 THP 大小取决于 CPU 架构，现代内核还支持 multi-size THP（16K、32K、64K 等）；但无论宿主机实际用多大的 THP，Firecracker 都要求 guest 内存大小是 2MB 的整数倍。

3. 选择2M时准备 hugetlbfs 页池。宿主机必须已有预分配的 2M 页池，池的管理方法见 docs/hugepages.md 指向的 Linux 内核文档。如果池太小，Firecracker 可能出现行为异常或收到SIGBUS信号——因为 Firecracker 映射 guest 内存时使用了MAP_NORESERVE标志，内核不会在mmap时预留足够的 hugetlbfs 页，而是按需从池中获取。

通过 API 配置 huge_pages

在另一个终端（Firecracker 进程保持运行）向/machine-config发送请求，PUT或PATCH均可。mem_size_mib和vcpu_count是MachineConfiguration的必填字段，以下取值取自集成测试用例：

API_SOCKET="/tmp/firecracker.socket" # 使用 2M hugetlbfs 大页 sudo curl -X PUT --unix-socket "${API_SOCKET}" \ --data '{ "mem_size_mib": 256, "vcpu_count": 2, "huge_pages": "2M" }' \ "http://localhost/machine-config"

改用 THP 时把"huge_pages"换成"Transparent"；不指定时字段默认为None。API 会做参数校验，取值非法（例如"7M"）时整个请求失败并返回 400（校验用例见 machine_configuration.rs）。Swagger 说明还强调：指定 2M hugetlbfs 页时mem_size_mib必须是 2 的整数倍。

除了 API 请求，也可以用--config-file传 JSON 配置文件直接启动 microVM，字段名与 API 请求相同（见 docs/getting-started.md 的 “Configuring the microVM without sending API requests” 一节，示例文件 vm_config.json）。

配置完成后，按常规流程设置 boot source、rootfs 并发送InstanceStart启动 microVM。

验证大页是否生效

2M模式：文档没有给出额外的宿主机检查命令，成功条件就是 microVM 正常启动运行；如果宿主机页池不足，现象是行为异常或SIGBUS，此时应回到宿主机扩充 2M 页池再试。

Transparent模式：可以按集成测试 test_huge_pages.py 的方法，检查 Firecracker 进程的 smaps 中AnonHugePages一项：

1. 在 guest 内分配并触摸一段匿名内存，触发宿主机侧的 guest 内存缺页（测试中使用）：

   python3 -c 'x = bytearray(128 * 1024 * 1024)'

2. 在宿主机统计 Firecracker 进程（下文记为 FIRECRACKER_PID，替换为你实际的进程 PID）的匿名大页总量（单位 kB）：

   awk '/AnonHugePages/{sum += $2} END{print sum}' /proc/FIRECRACKER_PID/smaps

3. 判断方式沿用测试的阈值：配置Transparent且 guest 触摸 128MiB 内存后，测试断言该值大于 64MiB（64 * 1024kB）；配置None时断言该值为 0。这些阈值是测试用例的判定条件，不是所有环境必须出现的固定数值，实际晋升多少页由内核机会性分配决定。

从快照恢复时的大页配置（可选分支）

如果 microVM 是从快照恢复的，PUT /snapshot/load也带一个huge_pages字段，取值比 boot 时多一个Snapshot（见 docs/hugepages.md 与 firecracker.yaml）：

• Snapshot：复用快照中序列化的配置，字段省略时默认就是它；
• None：使用主机默认的内存映射行为；
• Transparent、2M：分别对应相应的大页配置。

两个关键限制：显式2M要求 UFFD 内存后端，2M搭配 file-backed 恢复会返回错误；Transparent与 UFFD 组合虽被接受，但 UFFD 可能限制 THP 的实际效果。通过 UFFD 恢复快照时，Firecracker 会在初始握手阶段为每个内存区域发送配置的页大小（KiB），细节见 UFFD 快照恢复文档。

已知限制

以下限制直接抵消大页收益，规划内存策略前先确认（均出自 docs/hugepages.md）：

• 脏页追踪：对大页内存启用 dirty page tracking 会使大页收益失效，因为开启后 KVM 会无条件以 4K 粒度建立 guest 页表，即使宿主机使用大页映射。
• balloon：传统 balloon 设备按 4K 粒度汇报空闲页，无法回收大页支撑并降低 RSS；但 balloon 仍可以 inflate 用于限制 guest 内存使用。
• vhost-user-blk：使用该设备时 guest 内存是 memfd-backed（共享内存），共享内存的 THP 由/sys/kernel/mm/transparent_hugepage/shmem_enabled单独控制，默认可能未开启。
• UFFD：THP 与 UFFD 不集成，从快照恢复、userfault 处理期间不会分配 transparent huge pages。

性能预期

文档对收益的表述是：2M对特定负载可带来性能提升，来自更少的 TLB 竞争和更低的虚址到物理地址解析开销；也能减少快照恢复后重建扩展页表所需的 KVM_EXITS 次数，并改善启动时间——Firecracker 的 boot time 性能测试 测得最高可达 50%。这是文档给出的测量结论，不是所有环境的固定预期。

延伸阅读：docs/hugepages.md 中给出了 THP 与 hugetlbfs 的 Linux 内核文档入口，宿主机页池的预留与管理按内核文档操作；2M与Transparent的取舍本质上就是“是否需要确定性的预分配池”——需要确定性就用2M并管好页池，接受机会性分配就用Transparent。

【免费下载链接】firecrackerSecure and fast microVMs for serverless computing.项目地址: https://gitcode.com/GitHub_Trending/fi/firecracker