>我必须设计一种算法，该算法将决定将虚拟内核分配给VM。
例如，我有 2 个选项来创建machines。这可能是物理的/虚拟的。让我们考虑 2 种情况：
- 如果我需要 1 核
2.3 GHz，这意味着我需要一个能够运行2.3 * 10^9指令的处理器。在将具有这些功能的处理器分配给物理机的情况下，这是可以的。 - 但是，当我想将 1 核
2.3 GHz分配给虚拟机时，我想使用值为 0.8 的常量weight-factor。我将"指令数"即 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.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 中的代码不知道它不在真实硬件上运行);您可以跟踪"虚拟时间"和"挂钟时间"，并尝试保持这些时间大致同步。例如，如果"虚拟时间"移动得太慢(例如，因为虚拟机中的代码导致大量 VMEXIT)，您可以假装虚拟 CPU 变热并开始热节流，以创建一个合理/现实的借口，允许"虚拟时间"赶上"挂钟时间";如果某些事情可能比应有的更早发生(例如，您知道来宾正在等待一个将在 100 毫秒后过期的虚拟计时器，并且可以假装 100 毫秒过去了，而它没有过期)，您可以故意减慢虚拟机的速度，直到"挂钟时间"赶上"虚拟时间"。在这种情况下，最好给自己一些移动空间(假装虚拟 CPU 比它可能的速度慢，因为放慢虚拟机的速度比加快速度更容易)。当然，这也可用于隐藏由 SMT 引起的时序差异，并且可以隐藏由虚拟机之间共享 CPU 引起的时序差异(例如，当虚拟核心多于实际核心时)。
注意："替代选择"是说"虚拟时间"与"挂钟时间"完全无关。这允许您(例如)模拟 6 GHz CPU，而您拥有的只是一个旧的 1 GHz CPU - 这只是意味着 1"虚拟秒"大约需要 6 "挂钟秒"。
另请注意，由于过去 18+ 个月中的所有安全问题(例如幽灵)，我强烈建议使用"核心"作为最小可分配单元，以便在任何时候 VM 都会获得属于核心的所有逻辑 CPU，或者没有属于核心的逻辑 CPU(并拒绝允许同一内核中的逻辑 CPU 同时分配给不同的虚拟机， 因为数据可能会从一个 VM 泄漏到另一个 VM 的许多侧信道中的任何一个)。