Performance 用于确定虚拟机的虚拟核的权重因子

我必须设计一种算法，决定将虚拟核分配给

VM

e、 g.我有两个选项来创建

机器

。这可能是物理/虚拟的。让我们考虑2种情况：

• 如果我需要1核

  2.3 GHz

  ，这意味着我需要一个能够运行
  

  2.3*10^9

  指令的处理器。在将具有这些功能的处理器分配给物理机器的情况下，这是正常的
• 但是，当我想将

  2.3 GHz的1核
  分配给虚拟机时，我想使用一个值为0.8的常量
  权重因子。我将“指令数”即2.3*10^9除以权重因子
  0.8
  。因此，虚拟机所需的处理能力应按此因素进行缩放。结果表明，该值为2.875*10^9

我想向您保证，在虚拟机的情况下，这是通过使用权重因子来扩展所需处理能力的正确方法

如果是，是否有任何相关研究或概念证明可以使用此机制来确定虚拟机所需的处理器数量？

通常；用于80x86 CPU上的SMT（如超线程）；当核心内的所有逻辑CPU都在工作时：

• 如果所有逻辑CPU使用不同的资源（例如，一个使用SSE指令，另一个使用通用整数指令）；如果每个逻辑CPU是唯一使用内核的逻辑CPU，那么它的速度可能与它的速度一样快

• 如果所有逻辑CPU都在争夺相同的资源，则核心的性能可能会被逻辑CPU平均分配（例如，每个核心有2个逻辑CPU，每个逻辑CPU可能获得其性能的一半，如果它是使用核心的唯一逻辑CPU）

请注意，这也可能适用于AMD的推土机（即使它不被视为SMT），其中FPU在内核之间共享，但内核的其余部分不共享（换句话说，如果两个内核同时撞击FPU，则两个内核的性能都会受到影响）

这意味着（例如）对于每个核有2个逻辑CPU的

2.3GHz

核，每个逻辑CPU可能获得（粗略等效）0.75GHz到3.4GHz的任何值；取决于每个逻辑CPU执行的确切代码和各种电源管理条件（热节流、涡轮增压等）

然而，实际性能还取决于缓存（和缓存共享）、RAM芯片带宽和虚拟机开销（从导致大量VMExit的代码的“极端”到几乎为零）。考虑到这一点（例如）对于

2.3 GHz

内核，每个逻辑CPU可能获得（粗略等效）几百MHz到3.4 GHz的任何数据；这取决于许多因素

本质上；你的“权重”应该是0.1到1.0之间的任意随机数，这取决于你不知道/不知道的一堆东西

幸运的是，在虚拟机中运行的任何代码都可能被设计为能够处理各种不同的CPU，每种CPU的速度各不相同；因此，只需将任何CPU分配给虚拟机，并让虚拟机中运行的软件适应给定的性能就足够了

或者（如果您需要保证某种性能，或者您希望尝试隐藏时间差异，以便VM中的代码不知道它没有在真正的硬件上运行）；您可以跟踪“虚拟时间”和“挂钟时间”，并尝试保持这些时间大致同步。例如，如果“虚拟时间”移动太慢（例如，因为虚拟机内的代码导致大量VMExit），您可以假装虚拟CPU变热并开始热节流，以创建一个合理/现实的借口，允许“虚拟时间”赶上“墙上时钟时间”；如果某件事发生的时间比它应该发生的时间早（例如，您知道来宾正在等待一个虚拟计时器，该计时器将在100毫秒后过期，并且可以假装100毫秒过去了，而实际上它没有过期），您可以故意降低虚拟机的速度，直到“挂钟时间”赶上“虚拟时间”。在这种情况下，给自己一些移动的空间是一个好主意（假设虚拟CPU比实际速度慢，因为降低虚拟机的速度比提高虚拟机的速度容易）。当然，这也可以用来隐藏SMT引起的时间差，也可以隐藏VM之间共享CPU引起的时间差（例如，当虚拟核多于真实核时）

注：“替代方案”是指“虚拟时间”与“挂钟时间”完全无关。这允许你（例如）模拟一个6GHz的CPU，而你只有一个旧的1GHz CPU——这意味着1“虚拟秒”需要6“挂钟秒”

---

还注意到，在过去18个月的所有安全问题（如Simule）<强>中，我强烈认为使用“核”作为最小可赋值单元< /强>，使得在任何时间点，VM都获得属于核心或没有属于核心的逻辑CPU的所有逻辑CPU。（并拒绝将同一核心内的逻辑CPU同时分配给不同的虚拟机，因为数据可能会通过从一个VM到另一个VM的多个侧通道中的任何一个泄漏）。

权重因子是否应该表示虚拟化的开销？请注意，“

2.3 Ghz

”core很可能更像“

一个core，而不是以1.25 GHz（由于热节流）到3.4 GHz（由于“涡轮增压”）之间的任何速度运行”

”。这是开销，但不是机器的虚拟化，而是将其视为超线程开销。我想用一个系数告诉我每个周期需要多少额外的时钟