Virtual machine qemu:hugepages为宾客留下美好回忆

qemu-kvm

使用

-mem-prealloc-mem-path/mnt/hugepages/libvort/qemu

参数启动。这是否意味着来宾内存将从主机上的hugepages分配

此外，libvirt在域xml中定义了以下内容：

<memoryBacking>
    <hugepages/>
    <locked/>
</memoryBacking>

这基本上告诉虚拟机监控程序对其来宾内存使用

hugepages

，这些页面将被锁定在主机内存中（不允许交换）

这些选项是否一起工作（

-mem-prealloc

和libvirt的xml指令），并且一个是对另一个的补充？

元素将导致从默认的大页面大小池分配来宾RAM，并将导致在QEMU启动时立即分配这些大页面。巨大的页面总是锁定在主机RAM中

元素用于控制与来宾RAM分离的其他QEMU内存分配。它确保所有非来宾RAM页面也锁定在主机RAM中

如果您不想过度使用主机RAM，那么在主机端使用大型页面对于最大化性能是一个非常好的主意，因为它可以提高页面表命中率。无论来宾操作系统是否反过来使用巨大的页面，这都是正确的。此性能优势将适用于所有工作负载和所有来宾操作系统

---

当您试图过度分配主机RAM（即运行总RAM超过可用主机RAM的许多来宾）时，KSM功能将为您提供支持。它试图在来宾之间共享RAM页面，以避免在过度使用期间交换的风险。尽管KSM在CPU消耗方面有相当大的损失，因此它对于特定的工作负载和/或来宾操作系统是否有用是一个折衷。

我的主观观点：忘记hugepages吧，它带来的麻烦比它的帮助还多。很可能主机hugepages也会成为来宾中的hugepages，这会使您的整个内存管理处于次优状态。在prod环境中，出于这个原因，我特意从我的内核编译了hugepages支持，但非常精确地微调了ksm和zswap。“很好。”彼得·莫妮卡，谢谢你的反馈。您的意思是，在主机上分配的任何hugepage也可能是来宾内部的hugepage，因此它将被共享吗？如果您有kvm，这意味着您有内核支持将来宾资源映射到主机资源。包括网页。对我来说，将512个普通（4kB）访客页面映射到单个2M主机页面似乎是可能的，但这肯定不容易，而且目前Linux内核中甚至没有实现2MB页面的交换、压缩或samepage合并。（对于windows，世界上大概有10个人知道它是不是，但也可能不是，而且可能是出于同样的原因）。如果您需要执行许多页面操作（页面操作基本上是：1.映射到进程地址空间2.映射3.分配空闲页面4.分配空闲页面），Hugepages是很好的。这很好，但是如果你不能交换它们，如果你不能samepage合并它们，那么它可以加速哪些操作呢？然而，我知道的所有发行版默认内核都支持samepage（而且往往不支持zswap/ksm）。所以这是我个人的观点，我们有一个硬件功能，我们并不真正需要，但不实施它将是公关灾难。所以它被实施了，但没有人认为它真的很严重。