1 vmware的调度相对与linux增加了两个状态，co-start（协同开始）和co-stop（协同停止）

  当一个拥有多个vcpus的smp的虚拟机在进行调度时，会使用co-scheduling（协同调度）。就是当满足vcpus个物理cpu资源时。这个虚拟机的vcpus一起运行（co-start）。也会一起停止（co-stop）。这样的好处避免多个一个虚拟机的vcpu为了等待彼此资源而白白的浪费物理cpu的资源。

2 分为strict co-scheduling 和 relax co-scheduling

  1)一个虚拟机所有的vcpus同时运行和停止，这个叫strict co-schedling

  2) vcpus不相互依赖，它们可以在不同时间运行叫relax co-schedluing

  vmware用一个术语“skew”来决定什么时候co-start什么时候co-stop。在后来的调度里每个vcpus都计算自己的skew，当超过一定的阀值时就停止，这个vcpu就停止运行。其它不相关的vcpu继续运行。这个就是relax的co-scheduling的由来。

3 负载均衡

  vmare用一个术语叫“goodness”来表示一个“world”（理解为vcpu的进程）和一个目标cpu的组合分数。原则如下：

  1）cpu load

   优先考虑cpu负载小的。这样不需要等待就可以运行。

  2）LLC（LastLevel Cache）

  LLC就是最后一级的cache。它的下一级别就是物理的内存。cache访问与内存访问差这数量级的时延。一个numa内调度LLC都是共享的。如果是在numa内调度，那么cache的内容的共享（比如L1，L2等）就会放到第二位考虑了。

  3）Hyper-Threading

   如果有超线程的话。那么调度首先尽量避免同一个虚拟机里的vcpus在同一core上。在同一个core上的话，因为超线程会共享物理core的流水线，会导致性能下降。

  4）Topological Distance Between pCPUs

  pCPUs(物理cpu，理解为物理core)在硬件上是有拓扑（topological）距离的。如果跨socket迁移，那么要比对cache misss开销带来的代价是否比等待在一个忙的cpu划算。

  5）Co-scheduling

  这个与2相似。一个虚拟机的vcpus进程，不要在一个pCPUs上运行。

  6） Communication Between Scheduling Contexts

  这是考虑到如果一个虚拟里的两个"world"(vcpus进程或者线程)交互的比较频繁的话。调度器会调度他们到彼此离的近的pcpu上运行。保证cache的命中。

 

  本节总结：调度算法涉及的因子比较多。经过验证表明，vmware的调度的算法经过验证表现很好。“goodness”除了上面的原则还有如下经验

  1 一个”world“（vcpus的进程）保持运行在同一个pcpu上好于频繁的移动

  2 如果一个“world”频繁的选择同一cpu，那么该“world”对“goodness”的计算将会忽略一段时间。目的保持这个“world”的性能

4 Policy on Hyper-Threading

  由于超线程会带来性能的提升，但是不会带来双倍的增加。一个vpus如果占用一个完整的core那么效果要好于部分在一个逻辑cpu上的效果。vmware的早些的调度会完全等一个core在idle时在将vcpu调度上去。现在已经修改为当一个core有一个逻辑cpu处在idle时，也可以运行vcpu。虽然短时间内会带来vcpus之间不公平性，但是长时间还是公平的。这样的好处时充分利用了超线程的技术带了的性能提升

5 NUMA Scheduling Policy

  跨越NUMA访问远端的内存和迁移任务到远端cpu都会导致比较的时间延迟。本地NUMA能够满足虚拟机方位内存是最快的，本地访问为第一要义。以下为NUMA迁移的理论

  1）NUMA migration

  发生NUMA迁移的条件

  -1 解决短期的cpu load不均衡

   如果一个NUMA的cpu竞争大于另一个NUMA的话，这时候会发生NUMA迁移

  -2 NUMA迁移有利于提高内存访问

   如果一个NUMA上的cpu占有率比较高，会暂时迁移一个虚拟机到另一个NUMA上。当之前的NUAM在很短的时间变得不忙的时候，那么系统会再次迁移虚拟机到原来的NUMA上。前提是不会导致cpu的负载不均衡。这是因为虽然虚拟机调度到另一个NUMA上，但是他访问的内存还在前面的NUMA上。所以这种条件下，如果短时间内前一个NUMA变得不忙的话，将之前的虚拟机迁回去比较划算。

   备注：另一种情况，当迁移到另一个NUMA后，原来的NUMA并没有变的比较闲的时候，这个时候虚拟机不会再次调度到原来的NUMA上，此时会发生内存页的迁移。就是会将原来numa的本地内存访问的数据也迁移到虚拟机所在的NUMA上。

   内存随着任务的迁移而迁移这个在linux上也有。但是按照虚拟机的整体迁移是否在linux也是这样，这个需要调查。

  -3虚拟机之间频繁的交互会导致NUMA迁移

   如果两个虚拟机在不同的NUMA上运行，他们之间通信比较频繁，那么会将其中的一个虚拟机迁移到另一个虚拟机所在的NUMA上。这个会导致不均衡。用户可以通过设置/Numa/LocalityWeightActionAffinity这个属性为0，关闭这个特性。

  -4 虚拟机之间在长期内需要负载均衡

   如果需要达到虚拟机之间长期范围看是均衡的效果，那么就会发生NUMA迁移。比如有3个虚拟机在2个NUMA上运行，在任意短时间看都会有2个虚拟机在一个NUMA上运行，而另一个NUMA只跑一个虚拟机。这个就会导致NUMA迁移。迁移也会导致吞吐量的变小。所以，用户可以通过设置/Numa/LTermFairnessInterval为0来关闭这个特性

  2）Support for Wide Virtual Machines

  这个特性的意思是虚拟机支持比一个NUMA拥有物理CPU（超线程为逻辑cpu）更多的vcpus。比如，有两个NUMA，每个NUMA有4个core（每个core支持2个逻辑cpu）虚拟机可以支持8个以上的虚拟机的建立。指导用户建立虚拟机的原则是有如下三点：

  -1 建立的虚拟机最大的拥有的vcpus最好是按照NUMA中core的数量建立。根据上面的例子，一个虚拟机最大的设置是4个vcpu

  -2 其次，按照一个NUMA支持的逻辑cpu的数量。根据上面的例子，一个虚拟机最大的vcpus可以是8个

     备注：在原则1和原则2里虚拟机的调度按照NUMA调度原则，在同一个NUMA上调度。这个含有8个vcpus会在一个NUMA上调度。好处是性能得到提升，不好的是这个导致不均衡。用户可以通过numa.vcpu.preferHT设置来避免不均衡。

  -3 如果一个虚拟机建立超过了8个vcpus，那么调度也可以按照NUMA调度去做（之前不这么支持，是按照cpu逻辑算法去调度，导致vcpu在不同的NUMA上，内存访问会跨NUMA访问，导致性能下降）

     原则是系统会建立多个NUMA client分别管理不超过8个vcpus，每个NUMA client会按照NUMA调度。

    备注：在vsphere4以及之前，客户机的内核不能够看到物理NUMA的硬件拓扑结构。导致客户机分配内存的时候会随意分配，那么就会导致cpu跨NUMA访问了内存。在vphere5以后的版本里增加了下面的特性。

   3）vNUMA: Exposing NUMA Topology to a Virtual Machine

    这个特性就是暴露物理机的numa拓扑给虚拟机，虚拟机看到是vNUMA（比如，分配一个NUMA内的部分内存给虚拟机）。使得“wide”虚拟机（以上面例子说明的话，就是超过8vcpus为“wide”虚拟机）能够在vNUMA特性分配内存。这样避免交叉访问NUMA。

   4）vNUMA: Challenges and Best Practices

     vNUMA有第三点的好处，但也有很大的挑战。这个挑战来自于客户机不能自适应硬件NUMA的拓扑改变。比如：

     1）当主机有cpu和内内存的热插拔时，这个时候硬件的NUMA拓扑发生了改变，但是虚拟机里的拓扑仍然时原来启动时的配置。虚拟机不感知这个变化。

     2）当虚拟机迁移时，不同类型的主机NUMA时不同的，可能有小核机迁移到大核机，也可能相反。

     一旦虚拟机第一次发生了启动，当时的拓扑就伴随着这个虚拟机的生命周期。不感知的好处是，客户的应用不必调节。当然，如果想让虚拟机感知vNuMA的变化，可设置下面两个参数。

    numa.autosize TRUE

    numa.autosize.once FALSE

    默认是不感知。因为调节后有可能导致用户程序失败。为了避免用户程序运行失败，vmware维护了原来的vNUMA。那如何应对硬件的改变呢，这里有三点最佳的实践（Best Practices）。一共有三个场景，这个三个场景都有对应的策略。如下：

     场景1： 虚拟机的虚拟节点数小于迁移到目标host的NUMA数

     对应策略：这种情况下，系统会按照一个虚拟节点来创建一个NUMA Client。这种情况这个client一定能够满足本地化的内存分配。所以vNUMA的好处得到继承和发挥。

     场景2： 迁移目标的host的NUMA所拥有数比虚拟机的虚拟节点要小并且虚拟机的虚拟节点是物理NUMA的倍数关系

     对应策略：这种情况下，会分成多个NUMA Client共用一个虚拟节点。比如：一个32vcpu的虚拟机由原来的8core的NUMA迁移到一个4core的NUMA上。系统会创建一个还有8个vpu的虚拟节点, 这个虚拟节点有两个Numa Client，每个NUMA Client会管理4个vcpu。因为，一个虚拟节点会以轮循的方式满足两个client对内存的申请，这个虽然会导致两个client的对此虚拟节点的交叉访问虚拟节点带来的性能损失，但是也比访问不同的虚拟节点要快（因为不同的虚拟节点在不同的NUMA上，这样就导致了跨NUMA的访问）。

     场景3：迁移目标host的NUMA数小于虚拟机的虚拟节点的数量，并且虚拟节点的数量不是迁移到host机器上拥有numa数量的倍数

     对应策略：这种情况下，虚拟节点的拓扑被保留，NUMA client的创建就不管虚拟节点是否会交叉访问了。vNUMA机制在这个条件失效了