将超visor进程差异化到一组全局pCPU上的开销选项¶
https://blueprints.launchpad.net/nova/+spec/overhead-pin-set
Nova调度器和Placement API根据flavor中vCPU的数量确定CPU资源利用率和实例CPU放置。许多hypervisor都在宿主机OS上代表客户机实例执行操作。这些操作应该被统计和单独调度，并且应用它们自己的放置策略控制。
问题描述¶
之前引入了选项 hw:emulator_threads_policy，它为每个客户机添加额外的pCPU来运行模拟器线程。
虽然它解决了由于模拟器线程与vCPU固定在同一pCPU上导致的尖峰延迟问题，但一些操作员希望将所有模拟器线程打包到一组特定的pCPU上，以便允许更多的pCPU运行vCPU。
用例¶
作为操作员，我希望运行在特定pCPU集上的所有实例的所有模拟器线程。
项目优先级¶
无
提议的变更¶
为了扩展灵活性并解决主机资源有限的情况，“标准化CPU资源跟踪” spec 讨论了如何简化计算节点在CPU资源清单方面的配置，以及如何使专用CPU资源的定量跟踪与Placement API通过共享CPU资源的跟踪保持一致，引入了一个CONF选项 cpu_shared_set，它存储一个pinset字符串，指示应用于 VCPU 资源请求的物理处理器。
提议的更改是在这些共享主机CPU上运行模拟器线程的工作。希望利用此改进的flavor的管理员必须配置flavor extra-specs hw:emulator_threads_policy=share。
值得注意的是，hw:emulator_threads_policy=share 已经存在，但如果主机上未配置 CONF.cpu_shared_set，其默认行为将保持不变，这意味着模拟器线程将在专用于客户机的pCPU集上浮动。对于 hw:emulator_threads_policy=isolate，其行为将保持不变，这意味着将保留一个额外的pCPU来运行客户机模拟器线程。
备选方案¶
另一种选择是始终将模拟器线程固定到 CONF.cpu_shared_set。值得注意的是，删除实际提供的用户隔离客户机模拟器线程到专用pCPU或让客户机模拟器线程在整个专用于客户机的pCPU集上浮动的灵活性仍然是有效的选项，我们不应该删除这种灵活性。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
对于最终用户，在配置了 CONF.cpu_shared_set 的主机上使用选项 emulator_threads_policy=share 将改善运行敏感工作负载的客户机的延迟。
性能影响¶
无
其他部署者影响¶
希望将某些flavor配置为在pCPU之外运行其客户机模拟器线程的操作员，可以通过使用 CONF.cpu_shared_set 指定pCPU范围，并设置 hw:emulator_threads=share 来实现。
开发人员影响¶
其他虚拟化驱动程序的开发人员可能希望使用新的风味额外规范属性和调度器会计。如果使用stub domain功能，这将对Xen hypervisor特别感兴趣。
升级影响¶
N/A
实现¶
负责人¶
- 主要负责人
Sahid Orentino Ferdjaoui <sahid-ferdjaoui>
工作项¶
为计算节点引入
CONF.compute.cpu_shared_set选项当
emulator_threads_policy=share时，将客户机配置为将其模拟器线程固定到CONF.compute.cpu_shared_set
依赖项¶
CONF.compute.cpu_shared_set也在“标准化CPU资源跟踪” spec 中定义。这两个spec都可以引入此选项。
测试¶
这可以在任何能够测试当前NUMA和专用CPU策略的CI系统中进行测试。例如，它需要能够使用KVM而不是仅仅使用QEMU。将添加调度和驱动程序位（libvirt）的功能测试。
文档影响¶
描述NUMA和专用CPU策略使用情况的文档需要扩展到也描述这项工作引入的新选项。
参考资料¶
历史¶
Queen |
提议 |
|---|---|
Rocky |
重新提出 |
