Je lisais des articles TechNet ainsi que celui-ci concernant les différences entre la façon dont VMware et Hyper-V effectuent l’ordonnancement CPU.
Je me demandais si je pouvais obtenir des informations objectives à ce sujet. Il semblerait que l’ordonnancement en groupe utilisé par VMware soit un ÉNORME désavantage, mais je ne veux pas avaler aveuglément les arguments marketing. Cela a-t-il un impact sérieux sur les performances ou les dernières itérations des hyperviseurs VMware résolvent-elles ce problème ?
Modification : quand je dis désavantage, je veux dire par rapport à l’« ordonnancement de processeur libre » d’Hyper-V ou de KVM. Le matériel que je lisais ne mentionnait aucun problème avec l’« ordonnancement de processeur libre » qui serait évité avec l’ordonnancement en groupe.
Comme invoquer Bloody Mary devant un miroir de salle de bain mal éclairé, voyons si nous pouvons faire apparaître Jake Oshins…
L’ordonnancement en groupe est également appelé co-ordonnancement. Je pense que VMware préfère le terme co-ordonnancement à ordonnancement en groupe.
Dans les versions d’ESX antérieures à la version 3.x, VMware utilisait un co-ordonnancement « strict », qui avait les inconvénients de synchronisation. Dans ESX 3.x et supérieur, VMware est passé au co-ordonnancement « relâché ».
Le co-ordonnancement relâché a remplacé le co-ordonnancement strict dans ESX 3.x et a été affiné dans les versions suivantes pour obtenir une meilleure utilisation du CPU et prendre en charge les machines virtuelles à processeurs multiples larges. Le co-ordonnancement relâché a quelques propriétés distinctives par rapport à l’algorithme de co-ordonnancement strict. Le plus important de tous, alors que dans l’algorithme de co-ordonnancement strict, l’existence d’un vCPU en retard provoque le co-arrêt de toute la machine virtuelle. Dans l’algorithme de co-ordonnancement relâché, un vCPU en avance décide s’il doit se co-arrêter lui-même en fonction du décalage par rapport au vCPU frère le plus lent. Si le décalage est supérieur à un seuil, le vCPU en avance se co-arrête. Notez qu’un vCPU en retard est un vCPU qui fait significativement moins de progrès que le vCPU frère le plus rapide, tandis qu’un vCPU en avance est un vCPU qui fait significativement plus de progrès que le vCPU frère le plus lent. En suivant le vCPU frère le plus lent, il est désormais possible pour chaque vCPU de prendre sa propre décision de co-ordonnancement indépendamment. Comme le co-arrêt, la décision de co-démarrage est également prise individuellement. Une fois que le vCPU frère le plus lent commence à progresser, les vCPU co-arrêtés sont éligibles au co-démarrage et peuvent être planifiés en fonction de la disponibilité des pCPU. Cela résout le problème de fragmentation CPU de l’algorithme de co-ordonnancement strict en ne nécessitant pas qu’un groupe de vCPU soit planifié ensemble. Dans l’exemple précédent de la machine virtuelle à 4 vCPU, la machine virtuelle peut progresser même s’il n’y a qu’un seul pCPU inactif disponible. Cela améliore significativement l’utilisation du CPU.
L’extrait ci-dessus provient de la propre documentation de VMware.
VMware n’utilise donc plus l’ordonnancement en groupe strict. Je considérerais la documentation directement du fournisseur comme étant plus fiable.
La seule chose qui vous donnera des chiffres concrets est un benchmark, et cela dépendra entièrement des types de code exécutés par les CPU. Mais je peux vous dire que si VMware avait un tel désavantage, ils n’auraient pas encore la plus grande part du marché de la virtualisation.