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取值效果约束None默认使用主机默认页大小通常为 4K无大页行为无Transparent通过madvise(MADV_HUGEPAGE)请求 transparent huge pages由内核机会性分配无需预分配池guest 内存大小必须是 2MB 的整数倍2Mguest 内存由 2MB hugetlbfs 页支撑同上且要求宿主机有预分配的 2M 页池配置只能在 boot 之前完成PUT/PATCH /machine-config都是 pre-boot 操作必须在InstanceStart之前下发。准备工作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。选择Transparent时确认宿主机的 THP 设置。检查方法来自 test_huge_pages.py 的集成测试cat /sys/kernel/mm/transparent_hugepage/enabled输出形如always [madvise] never方括号内为当前生效项。测试要求该值为madvise或always否则 THP 无法生效。另外注意即使传统 THP 在 x86_64 上是 2MBPMD 大小实际 THP 大小取决于 CPU 架构现代内核还支持 multi-size THP16K、32K、64K 等但无论宿主机实际用多大的 THPFirecracker 都要求 guest 内存大小是 2MB 的整数倍。选择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一项在 guest 内分配并触摸一段匿名内存触发宿主机侧的 guest 内存缺页测试中使用python3 -c x bytearray(128 * 1024 * 1024)在宿主机统计 Firecracker 进程下文记为 FIRECRACKER_PID替换为你实际的进程 PID的匿名大页总量单位 kBawk /AnonHugePages/{sum $2} END{print sum} /proc/FIRECRACKER_PID/smaps判断方式沿用测试的阈值配置Transparent且 guest 触摸 128MiB 内存后测试断言该值大于 64MiB64 * 1024kB配置None时断言该值为 0。这些阈值是测试用例的判定条件不是所有环境必须出现的固定数值实际晋升多少页由内核机会性分配决定。从快照恢复时的大页配置可选分支如果 microVM 是从快照恢复的PUT /snapshot/load也带一个huge_pages字段取值比 boot 时多一个Snapshot见 docs/hugepages.md 与 firecracker.yamlSnapshot复用快照中序列化的配置字段省略时默认就是它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单独控制默认可能未开启。UFFDTHP 与 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 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取值效果约束None默认使用主机默认页大小通常为 4K无大页行为无Transparent通过madvise(MADV_HUGEPAGE)请求 transparent huge pages由内核机会性分配无需预分配池guest 内存大小必须是 2MB 的整数倍2Mguest 内存由 2MB hugetlbfs 页支撑同上且要求宿主机有预分配的 2M 页池配置只能在 boot 之前完成PUT/PATCH /machine-config都是 pre-boot 操作必须在InstanceStart之前下发。准备工作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。选择Transparent时确认宿主机的 THP 设置。检查方法来自 test_huge_pages.py 的集成测试cat /sys/kernel/mm/transparent_hugepage/enabled输出形如always [madvise] never方括号内为当前生效项。测试要求该值为madvise或always否则 THP 无法生效。另外注意即使传统 THP 在 x86_64 上是 2MBPMD 大小实际 THP 大小取决于 CPU 架构现代内核还支持 multi-size THP16K、32K、64K 等但无论宿主机实际用多大的 THPFirecracker 都要求 guest 内存大小是 2MB 的整数倍。选择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一项在 guest 内分配并触摸一段匿名内存触发宿主机侧的 guest 内存缺页测试中使用python3 -c x bytearray(128 * 1024 * 1024)在宿主机统计 Firecracker 进程下文记为 FIRECRACKER_PID替换为你实际的进程 PID的匿名大页总量单位 kBawk /AnonHugePages/{sum $2} END{print sum} /proc/FIRECRACKER_PID/smaps判断方式沿用测试的阈值配置Transparent且 guest 触摸 128MiB 内存后测试断言该值大于 64MiB64 * 1024kB配置None时断言该值为 0。这些阈值是测试用例的判定条件不是所有环境必须出现的固定数值实际晋升多少页由内核机会性分配决定。从快照恢复时的大页配置可选分支如果 microVM 是从快照恢复的PUT /snapshot/load也带一个huge_pages字段取值比 boot 时多一个Snapshot见 docs/hugepages.md 与 firecracker.yamlSnapshot复用快照中序列化的配置字段省略时默认就是它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单独控制默认可能未开启。UFFDTHP 与 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考