确定虚拟机的虚拟内核的权重因子
Weight-factor to determine Virtual Cores for a Virtual Machine
我必须设计一个算法来决定将虚拟内核分配给 VM。
例如我有 2 个选项来创建 machines。那可能是 physical/virtual。让我们考虑两种情况：
- 如果我需要
2.3 GHz 的 1 核，这意味着我需要一个能够执行 运行
2.3 * 10^9 指令的处理器。在将具有这些能力的处理器分配给物理机的情况下，是可以的。
- 但是当我想将
2.3 GHz 的 1-core 分配给虚拟机时，我想使用一个值为 0.8 的常量 weight-factor。我将 "number of instructions" 即 2.3 * 10^9 除以权重因子 0.8。因此，虚拟机所需的处理能力应该通过这个因素来衡量。结果是 2.875 * 10^9.
我想向您确认一下，在虚拟机的情况下，这是通过使用权重因子来扩展所需处理能力的正确方法吗？
如果是，是否有任何相关研究或概念证明来使用这种确定虚拟机所需处理器数量的机制？
一般；对于 80x86 CPUs 上的 SMT（例如 hyper-threading）；一个核心中的所有逻辑 CPU 都在工作：
如果所有逻辑 CPU 都使用不同的资源（例如，可能一个使用 SSE 指令而另一个使用通用整数指令）；如果每个逻辑 CPU 是唯一使用核心
如果所有逻辑CPU都在争夺同一个resource/s，核心的性能可能会被逻辑CPU平分（例如每个核心有 2 个逻辑 CPU，如果它是唯一使用核心的逻辑 CPU，每个逻辑 CPU 可能会获得一半的性能。
请注意，这也可能适用于 AMD 的 Bulldozer（即使它不被视为 SMT），其中 FPU 在内核之间共享，但内核的其余部分不是（换句话说，如果两个内核都在冲击 FPU同时，两个内核的性能都会受到影响。
这意味着（例如）对于每个核心有 2 个逻辑 CPU 的 2.3 GHz 核心，每个逻辑 CPU 可能会获得（粗略等效于）0.75 GHz 的任何频率至 3.4 GHz；取决于每个逻辑 CPU 恰好正在执行的确切代码和各种电源管理条件（热节流、turbo-boost 等）。
然而，实际性能还取决于缓存（和缓存共享）、RAM 芯片带宽和虚拟机开销（从 "extreme" 代码导致大量 VMEXIT 到几乎没有） .考虑到这一点（例如）对于 2.3 GHz 内核，每个逻辑 CPU 可能会获得（粗略等效）从几百 MHz 到 3.4 Ghz 的任何频率；取决于很多因素。
本质上；你的 "weight" 应该是 0.1 到 1.0 之间的任意随机数，具体取决于一堆你无法t/won不知道的东西。
幸运的是，虚拟机中的任何代码 运行 都可能被设计为处理各种不同的 CPU，每个代码的速度各不相同；所以只需将任何 CPU 分配给虚拟机并让虚拟机内的软件 运行 适应它所提供的任何性能就足够了。
或者（如果您需要保证某种性能，或者您想尝试隐藏时间差异，以便 VM 中的代码不知道它不是 运行 在真实硬件上）；您可以跟踪 "virtual time" 和 "wall clock time" 并尝试使这些时间大致同步。例如，如果 "virtual time" 移动得太慢（例如，因为 VM 内部的代码导致大量 VMEXIT），您可以假装虚拟 CPU 变热并开始热节流以创建 plausible/realistic 允许 "virtual time" 赶上 "wall clock time" 的借口；如果某些事情发生的时间比它应该发生的要早（例如，您知道来宾正在等待一个虚拟计时器，该计时器将在 100 毫秒后到期，并且可以假装 100 毫秒过去了，但实际上并没有），您可以故意减慢虚拟机的速度，直到 "wall clock time" 赶上 "virtual time"。在这种情况下，给自己一些移动空间是个好主意（假装虚拟机 CPU 比实际速度慢，因为降低虚拟机速度比加速虚拟机更容易）。当然这也可以用来隐藏由 SMT 引起的时序差异，并且可以隐藏由 VM 之间共享 CPUs 引起的时序差异（例如当虚拟内核比真实内核多时）。
注："alternative alternative"是说"virtual time"与"wall clock time"完全没有关系。这允许您（例如）模拟 6 GHz CPU，而您只有一个旧的 1 GHz CPU - 这只是意味着 1 "virtual second" 需要大约 6 "wall clock seconds".
另请注意，由于过去 18 个月以上的所有安全问题（例如幽灵）我强烈考虑使用 "cores" 作为最小可分配单位，这样，在任何时间点，VM 都会获得属于核心的所有逻辑 CPU 或属于核心的逻辑 CPU 的 none（并拒绝允许逻辑 CPUs 在同一核心内同时分配给不同的虚拟机，因为数据可能会从一个虚拟机到另一个虚拟机的许多 side-channels 中的任何一个泄漏。
我必须设计一个算法来决定将虚拟内核分配给 VM。
例如我有 2 个选项来创建 machines。那可能是 physical/virtual。让我们考虑两种情况：
- 如果我需要
2.3 GHz的 1 核，这意味着我需要一个能够执行 运行2.3 * 10^9指令的处理器。在将具有这些能力的处理器分配给物理机的情况下，是可以的。 - 但是当我想将
2.3 GHz的 1-core 分配给虚拟机时，我想使用一个值为 0.8 的常量weight-factor。我将 "number of instructions" 即 2.3 * 10^9 除以权重因子0.8。因此，虚拟机所需的处理能力应该通过这个因素来衡量。结果是 2.875 * 10^9.
我想向您确认一下，在虚拟机的情况下，这是通过使用权重因子来扩展所需处理能力的正确方法吗？
如果是，是否有任何相关研究或概念证明来使用这种确定虚拟机所需处理器数量的机制？
一般；对于 80x86 CPUs 上的 SMT（例如 hyper-threading）；一个核心中的所有逻辑 CPU 都在工作：
如果所有逻辑 CPU 都使用不同的资源（例如，可能一个使用 SSE 指令而另一个使用通用整数指令）；如果每个逻辑 CPU 是唯一使用核心
的逻辑 CPU，那么它可能会一样快
如果所有逻辑CPU都在争夺同一个resource/s，核心的性能可能会被逻辑CPU平分（例如每个核心有 2 个逻辑 CPU，如果它是唯一使用核心的逻辑 CPU，每个逻辑 CPU 可能会获得一半的性能。
请注意，这也可能适用于 AMD 的 Bulldozer（即使它不被视为 SMT），其中 FPU 在内核之间共享，但内核的其余部分不是（换句话说，如果两个内核都在冲击 FPU同时，两个内核的性能都会受到影响。
这意味着（例如）对于每个核心有 2 个逻辑 CPU 的 2.3 GHz 核心，每个逻辑 CPU 可能会获得（粗略等效于）0.75 GHz 的任何频率至 3.4 GHz；取决于每个逻辑 CPU 恰好正在执行的确切代码和各种电源管理条件（热节流、turbo-boost 等）。
然而，实际性能还取决于缓存（和缓存共享）、RAM 芯片带宽和虚拟机开销（从 "extreme" 代码导致大量 VMEXIT 到几乎没有） .考虑到这一点（例如）对于 2.3 GHz 内核，每个逻辑 CPU 可能会获得（粗略等效）从几百 MHz 到 3.4 Ghz 的任何频率；取决于很多因素。
本质上；你的 "weight" 应该是 0.1 到 1.0 之间的任意随机数，具体取决于一堆你无法t/won不知道的东西。
幸运的是，虚拟机中的任何代码 运行 都可能被设计为处理各种不同的 CPU，每个代码的速度各不相同；所以只需将任何 CPU 分配给虚拟机并让虚拟机内的软件 运行 适应它所提供的任何性能就足够了。
或者（如果您需要保证某种性能，或者您想尝试隐藏时间差异，以便 VM 中的代码不知道它不是 运行 在真实硬件上）；您可以跟踪 "virtual time" 和 "wall clock time" 并尝试使这些时间大致同步。例如，如果 "virtual time" 移动得太慢（例如，因为 VM 内部的代码导致大量 VMEXIT），您可以假装虚拟 CPU 变热并开始热节流以创建 plausible/realistic 允许 "virtual time" 赶上 "wall clock time" 的借口；如果某些事情发生的时间比它应该发生的要早（例如，您知道来宾正在等待一个虚拟计时器，该计时器将在 100 毫秒后到期，并且可以假装 100 毫秒过去了，但实际上并没有），您可以故意减慢虚拟机的速度，直到 "wall clock time" 赶上 "virtual time"。在这种情况下，给自己一些移动空间是个好主意（假装虚拟机 CPU 比实际速度慢，因为降低虚拟机速度比加速虚拟机更容易）。当然这也可以用来隐藏由 SMT 引起的时序差异，并且可以隐藏由 VM 之间共享 CPUs 引起的时序差异（例如当虚拟内核比真实内核多时）。
注："alternative alternative"是说"virtual time"与"wall clock time"完全没有关系。这允许您（例如）模拟 6 GHz CPU，而您只有一个旧的 1 GHz CPU - 这只是意味着 1 "virtual second" 需要大约 6 "wall clock seconds".
另请注意，由于过去 18 个月以上的所有安全问题（例如幽灵）我强烈考虑使用 "cores" 作为最小可分配单位，这样，在任何时间点，VM 都会获得属于核心的所有逻辑 CPU 或属于核心的逻辑 CPU 的 none（并拒绝允许逻辑 CPUs 在同一核心内同时分配给不同的虚拟机，因为数据可能会从一个虚拟机到另一个虚拟机的许多 side-channels 中的任何一个泄漏。