Virt 驱动程序用于客户机 RAM 的大页面分配

https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages

此功能旨在改进 libvirt 驱动程序，使其能够使用大页面来支持客户机 RAM 分配。这将通过提高 TLB 缓存效率来提高客户机工作负载的性能。它将确保客户机拥有 100% 专用 RAM，绝不会被交换出去。

问题描述

大多数现代虚拟化主机支持各种内存页面大小。在 x86 上，最小的，默认由内核使用，是 4kb，而较大的尺寸包括 2MB 和 1GB。CPU TLB 缓存具有有限的大小，因此当存在大量 RAM 并被利用时，缓存效率可能非常低，从而增加内存访问延迟。通过使用更大的页面大小，TLB 中需要的条目更少，因此其效率更高。

为客户机提供支持使用大页面意味着客户机正在使用专用资源分配运行。即，内存超卖的概念不再可能提供。这是云管理员愿意为了支持需要可预测内存访问时间的工作负载（例如 NFV）而做出的权衡。

虽然大页面比小页面好，但不能假定收益会随着页面大小的增加而增加。在某些工作负载中，2 MB 页面大小可能比 1 GB 页面大小更好。此外，页面大小的选择会影响客户机 RAM 大小的粒度。例如，1.5 GB 的客户机将无法使用 1 GB 页面，因为 RAM 不是页面大小的倍数。

虽然理论上可以在主机启动后动态地预留大页面，但经过一段时间后，物理内存会变得非常碎片化。这意味着即使主机有大量的可用内存，也可能无法找到提供大页面所需的连续块。这对于 1 GB 大小的页面来说尤其成问题。为了解决这个问题，通常的做法是在主机启动时提前预留所有必需的大页面，方法是在主机的内核命令行中指定预留计数。这将是在部署新的计算节点主机时执行的一次性设置任务。

用例

大页面可以用作提供专用资源客户机的途径，因为大页面必须一次分配给一个客户机。与将 RAM 超卖比率设置为 0 相比，优势在于与大页面关联的内存不能被交换或用于操作系统的其他目的。它始终保证分配给客户机操作系统。

从性能角度来看，大页面通过提高处理器中 TLB 缓存命中率来提供改进的内存访问延迟。此优势对于需要对客户机性能进行严格保证的工作负载（例如网络功能虚拟化 (NFV) 部署）非常重要。

项目优先级

无

提议的变更

flavor 的 extra specs 将得到增强，以支持新的参数

• hw:mem_page_size=large|any|2MB|1GB

如果 flavor 中没有设置任何页面大小，则将继续使用当前行为，即使用小的默认页面大小。设置 ‘large’ 表示仅对客户机 RAM 使用较大的页面大小，例如 x86 上的 2MB 或 1GB；‘any’ 表示将策略留给计算驱动程序实现来决定。看到 ‘any’ 时，libvirt 驱动程序可能会尝试查找大页面，但回退到小页面，但其他驱动程序可能会为 ‘any’ 选择替代策略。最后，如果工作负载对特定的页面大小有非常精确的要求，则可以设置显式的页面大小。预计常见情况将是使用 page_size=large 或 page_size=any。显式页面大小的指定将是 NFV 工作负载所需要的。

可以针对 image 定义 flavor 中定义的属性，但只有当 flavor 已经具有 ‘large’ 或 ‘any’ 策略时，才会尊重使用大页面的请求。即，如果 flavor 指定了特定的数字页面大小，则不允许 image 覆盖此设置以访问其他大页面大小。image 中的此类无效覆盖将导致引发异常，并且尝试启动实例将导致错误。虽然最终验证是在 virt 驱动程序中完成的，但也可以在 API 层捕获并报告此错误。

如果 flavor 内存大小不是指定的巨大页面大小的倍数，则将被视为错误，这将导致实例无法启动。如果页面大小为 ‘large’ 或 ‘any’，则计算驱动程序显然会尝试选择一个页面大小，该页面大小是 RAM 大小的倍数，而不是报错。只有在使用 1 GB 页面大小时，这才可能成为一个重要问题，这意味着 RAM 大小必须以 1 GB 为增量。

libvirt 驱动程序将得到增强，以在配置客户机 RAM 分配策略时尊重此参数。这实际上将引入“专用内存”客户机的概念，因为大页面必须与客户机 1:1 关联 - 没有通过允许一个大页面与多个客户机一起使用或交换大页面来进行超卖的机制。

libvirt 驱动程序将得到增强，以报告每个 NUMA 节点的可用大页面，建立在先前添加的 NUMA 拓扑报告之上。

调度器将得到增强，以考虑 flavor 上的页面大小设置，并在调度实例时选择具有足够大页面可用的主机。相反，如果未请求大页面，则调度器需要避免将实例放置在预留了大页面的主机上。调度器的增强将在作为 NUMA 拓扑蓝图的一部分实施的新过滤器中完成。这涉及更改该蓝图中的逻辑，以便它不仅查看每个 NUMA 节点中的可用内存，还查看所需页面大小的可用页面计数。

如本文档稍后所示，每个主机将报告所有可用页面大小，并且此信息将可供调度器使用。在解释 ‘large’ 时，它将考虑任何页面大小，但最小的页面大小除外。这显然意味着 ‘large’ 和 ‘small’ 可能因所考虑的主机而异。对于会出现此问题的使用场景，将请求显式的页面大小，而不是使用这些符号命名的大小。它还需要考虑页面大小是否是 flavor 内存大小的倍数。如果实例使用多个 NUMA 节点，则它需要考虑每个客户机节点中的 RAM 是否是页面大小的倍数，而不是总内存大小。

备选方案

最近的 Linux 主机具有“透明大页面”的概念，其中内核会为客户机 VM 动态地分配大页面。问题在于，随着时间的推移，内核的内存分配会变得非常碎片化，从而越来越难以找到用于大页面的连续 RAM 块。这使得透明大页面不适用于 1 GB 页面大小。机会主义方法也意味着用户没有任何保证他们的实例将由大页面支持。这使其成为 NFV 工作负载无法使用的方案，这些工作负载需要严格的保证。

数据模型影响

先前添加到主机状态结构中的用于报告 NUMA 拓扑的数据将得到增强，以进一步包含有关每个节点页面大小可用性的信息。因此，它将如下所示

hw_numa = {
   nodes = [
       {
          id = 0
          cpus = 0, 2, 4, 6
          mem = {
             total = 10737418240
             free = 3221225472
          },
          mempages = [{
               size_kb = 4,
               total = 262144,
               used = 262144,
             }, {
               size_kb = 2048,
               total = 1024,
               used = 1024,
             }, {
               size_kb = 1048576,
               total = 7,
               used = 0,
             }
          ]
          distances = [ 10, 20],
       },
       {
          id = 1
          cpus = 1, 3, 5, 7
          mem = {
             total = 10737418240
             free = 5368709120
          },
          mempages = [{
               size_kb = 4,
               total = 262144,
               used = 512,
             }, {
               size_kb = 2048,
               total = 1024,
               used = 128,
             }, {
               size_kb = 1048576,
               total = 7,
               used = 4,
             }
          ]
          distances = [ 20, 10],
       }
   ],
}

REST API 影响

没有影响。

现有的 API 已经支持 flavor 附加规格中的任意数据。

安全影响

没有影响。

通知影响

没有影响。

通知系统未被此更改使用。

其他最终用户影响

没有直接影响最终用户，除了他们的客户机应该具有更可预测的内存访问延迟之外。

性能影响

调度器将添加更多逻辑，以在放置客户机时考虑每个 NUMA 节点的可用大页面。大部分影响将已经在将 NUMA 支持添加到调度器时产生。此更改只是更改了 NUMA 支持，以便它考虑可用的大页面而不是总 RAM 大小。

其他部署者影响

云管理员将获得设置他们配置的 flavor 上大页面策略的能力。管理员还必须配置他们的计算主机以在启动时预留大页面，并将这些主机置于使用聚合中。

可能需要通过 Nova API 向主机管理员公开有关页面计数的更多信息。可以在完成本文档中参考的基本规范中的工作后，考虑这种需求。

开发人员影响

如果其他 hypervisor 允许控制大页面使用，则可以对其进行增强以支持相同的 flavor extra specs 设置。如果 hypervisor 对大页面使用具有自我确定的控制权，则可以简单地忽略此新的 flavor 设置。即，不执行任何操作。

实现

负责人

主要负责人

sahid

其他贡献者

ndipanov berrange

工作项

• 增强 libvirt 驱动程序，以在主机状态数据中报告每个 NUMA 节点的可用大页面

• 增强 libvirt 驱动程序，以根据 flavor 参数配置页面大小的客户机

• 添加对调度器的支持，以根据所需的可用大页面将实例放置在主机上

依赖项

• Virt 驱动程序客户机 NUMA 节点放置和拓扑。此蓝图将是对计算驱动程序和调度器中为 NUMA 放置所做工作的扩展，因为大页面必须从匹配的客户机和主机 NUMA 节点分配，以避免跨节点内存访问

  https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement

• 需要增强 Libvirt / KVM，以允许 Nova 指示应从主机上的特定 NUMA 节点分配大页面。这并不是支持 Nova 中大页面的障碍，因为它可以使用 libvirt 中更通用的支持大页面，但是，在可以对每个 NUMA 节点进行大页面分配之前，性能优势将无法完全实现。

测试

在 gate 中测试起来很困难，因为运行 gate 测试的主机必须在初始 OS 启动时配置为分配大页面。反过来，这将排除使用不希望使用大页面的客户机运行 gate 测试。

文档影响

需要记录云管理员可用的新 flavor 参数以及有关有效使用情况的建议。文档还需要提及计算主机部署先决条件，例如需要在启动时预分配大页面和设置聚合。

参考资料

当前关于 CPU 和内存资源利用率和放置主题的“大图景”研究和设计。 vCPU 拓扑是这项工作的一个子集

• https://wiki.openstack.org/wiki/VirtDriverGuestCPUMemoryPlacement

先前已获得 Juno 的批准，但实施未完成

• https://review.openstack.org/93653