问题陈述（带有示例）
我必须设计一种算法，该算法将决定将虚拟内核分配给VM。
例如我有2个选项来创建machines。那可能是物理/虚拟的。让我们考虑2种情况：
2.3 GHz，则意味着我需要具有能够运行2.3 * 10^9指令的处理器。如果将具有这些功能的处理器分配给物理机，则可以。2.3 GHz的1核分配给虚拟机时，我想使用值为0.8的常量weight-factor。我用加权因子0.8除以“指令数”，即2.3 * 10 ^ 9。因此，虚拟机所需的处理能力应以此比例来缩放。值变成2.875 * 10 ^ 9。在虚拟机的情况下，我想向大家保证，这是通过使用加权因子来扩展所需处理能力的正确方法。
如果是，是否有任何相关研究或概念证明可使用这种机制确定虚拟机所需的处理器数量？
答案 0 :(得分：1)
一般而言；适用于80x86 CPU上的SMT（例如超线程）；核心中的所有逻辑CPU都在工作：
如果所有逻辑CPU都在使用不同的资源（例如，一个可能使用SSE指令，另一个可能使用通用整数指令）；每个逻辑CPU的速度可能与使用核心的唯一逻辑CPU的速度一样快
如果所有逻辑CPU都在争夺相同的资源，则内核的性能可以除以逻辑CPU（例如，每个内核有2个逻辑CPU，每个逻辑CPU可能获得一半的性能）。如果它是唯一使用该内核的逻辑CPU，则将具有此功能。
请注意，这可能还适用于AMD的Bulldozer（即使不视为SMT），其中FPU在内核之间共享，而其余内核则不共享（换句话说，如果两个内核都在FPU上敲击FPU）同时将影响两个内核的性能。
这意味着（例如）对于每个内核具有2个逻辑CPU的2.3 GHz内核，每个逻辑CPU可能会获得0.75 GHz至3.4 Ghz的任何值（大致等效）；取决于每个逻辑CPU恰好正在执行的确切代码以及各种电源管理条件（热节流，涡轮增压等）。
但是，实际性能还取决于诸如高速缓存（和高速缓存共享），RAM芯片带宽和虚拟机开销（它们因导致大量VMEXIT的代码的“极端”而几乎没有）的不同。考虑到这一点（例如，对于2.3 GHz内核），每个逻辑CPU都可以获取（粗略等价的）从几百MHz到3.4 Ghz的任何值；取决于许多因素。
本质上；您的“权重”应该是0.1到1.0之间的任意随机数，具体取决于一堆您不知道/不知道的东西。
幸运的是，虚拟机内部运行的任何代码都可能被设计为处理各种不同的CPU，每个CPU的速度各不相同。因此只需将任何CPU分配给虚拟机就足够了，让虚拟机内部运行的软件适应所提供的任何性能。
或者（如果您需要保证某种性能，或者想隐藏时序差异，以使VM中的代码不知道它不在实际硬件上运行）；您可以跟踪“虚拟时间”和“挂钟时间”，并尝试使这些时间大致保持同步。例如，如果“虚拟时间”移动太慢（例如，由于VM中的代码导致大量VMEXIT），则您可以假装虚拟CPU变热并开始热节流，以创建合理的/现实的借口，从而允许“虚拟时间”赶上“挂钟时间”；如果发生的事情比预期的要早（例如，您知道来宾正在等待一个虚拟计时器，该计时器将在100毫秒内到期，并且可以假装该计时器没有经过100毫秒），则可以故意降低虚拟机的速度，直到“挂钟时间”赶上“虚拟时间”。在这种情况下，最好给自己一些移动的空间（假装虚拟CPU的速度慢于它的速度，因为减慢虚拟机的速度要比加速虚拟机容易）。当然，这也可以用来隐藏由SMT引起的时序差异，也可以隐藏在VM之间共享CPU造成的时序差异（例如，当虚拟内核多于实际内核时）。
注意：“替代方案”是指“虚拟时间”与“挂钟时间”完全无关。这样，当您拥有的只是一个旧的1 GHz CPU时，您可以（例如）仿真一个6 GHz CPU-这仅意味着1个“虚拟秒”大约需要6个“挂钟秒”。
还请注意，在过去18个月以上的所有安全问题（例如幽灵）中，我强烈考虑使用“核心”作为最小可分配单位，以便在任何时间点VM会获取属于某个核心的所有逻辑CPU，或者不获取属于该核心的所有逻辑CPU（并且拒绝允许将同一核心内的逻辑CPU同时分配给不同的虚拟机，因为数据可能会跨任何虚拟机泄漏）一个虚拟机到另一个虚拟机的许多旁通道）。