VirtualBox: Est-ce une mauvaise idée d'assigner plus de kernelx de CPU virtuels que le nombre de kernelx de CPU physiques

Comme je dispose d'un processeur Hyper-Threading capable, je me request, est-ce une mauvaise idée d'assigner plus de cœurs de processeur virtuel que le nombre de cœurs physiques de processeur comme l'avertissement suivant suggère:

Avertissement VirtualBox

Transcription:

Plus de CPU virtuels sont atsortingbués à la machine virtuelle que le nombre de CPU physiques sur le système hôte. Ceci est susceptible de dégrader les performances de votre machine virtuelle. Veuillez envisager de réduire le nombre de processeurs virtuels.

Quelqu'un peut-il raisonner sur ce sujet?

EDIT1:

Le processeur en question est Intel Core i7-4700HQ, Ark Intel , CPU Benchmark

EDIT2:

En supposant qu'il n'y ait pas de matériel obsolète, comme un disque dur (au lieu d'un SSD) et / ou une memory vive (16 Go, minimum vm.swappiness , 4 Go pour cette machine virtuelle), etc.

Dans mon cas particulier, lorsque ce qui suit s'applique:

Hôte : Linux Mint 18 Cannelle 64 bits (entièrement mis à jour); Version du kernel 4.4.0-47-generic

Invité : Windows 8.1 Pro 64 bits (entièrement mis à jour)

Processeur : Intel Core i7-4700HQ , (6 Mo de memory cache, 4 kernelx physiques ou 8 en utilisant l'hyperthreading), CPU Benchmark

VirtualBox : Version 5.1.10 r112026 (Qt5.5.1)

Ajouts invités : installés et à jour

devise de reference n ° 1 : WinRAR version 5.40 final 64 bits

devise de reference n ° 2 : VeraCrypt version 1.19 final 64 bits

Préparation: Dans les deux cas, j'ai attendu après le démarrage jusqu'à ce que le CPU, la RAM, le lecteur de disque soient stables près des points zéro.

Méthode :

  1. Clonage de la machine virtuelle d'origine pour en avoir deux identiques.
  2. J'ai, pour la deuxième passe, depuis le redémarrage désactivé Antivirus souligné au bas de cette réponse et mis à jour WinRAR dans les deux cas d'un bêta à la version finale.
  3. J'ai fait la même préparation que précédemment.
  4. La machine virtuelle a couru au premier plan, sans autre application gourmande en time CPU, j'ai désactivé ce que je pouvais pour que le test ne soit pas influencé.
  5. Pour inclure la caching potentielle à l'intérieur ou à l'extérieur du système, j'ai effectué le même test deux fois par la suite. Le bénéfice étant presque nul.

WinRAR benchmark avec 4 coeurs activés, 1.5GiB traités en 7.5 minutes:

WinRAR benchmark avec 4 coeurs activés

WinRAR benchmark avec 8 coeurs activés, 1.5GiB traités en 4.5 minutes:

Benchmark WinRAR avec 8 coeurs activés

J'ai mis à jour les résultats, car j'ai oublié de désactiver le système Antivirus sur l'hôte et le operating system client, ce qui a donné des résultats plus précis maintenant.


Benchmark VeraCrypt avec 4 coeurs activés, vitesse AES accélérée HW 2,6 Gb / s:

Benchmark VeraCrypt avec 4 coeurs activés

Benchmark VeraCrypt avec 8 cœurs activés, vitesse AES accélérée HW 3.9 Gb / s:

Benchmark VeraCrypt avec 8 coeurs activés

J'ai mis à jour les résultats car, encore une fois , j'ai oublié de désactiver le système Antivirus sur l'hôte et le operating system client, ce qui a donné des résultats plus précis maintenant.


Je pourrais exécuter autant de tests que nécessaire. Mais je figure, si ces deux, dont l'un est un test de compression plutôt complexe, le second étant un set de tests de encryption plutôt complexes, quel serait le point.


Conclusion: Les deux benchmarks montrent une différence marquée. Je ne vois aucune raison de croire que leurs résultats sont inexacts, car j'ai suivi une préparation et une méthode plutôt rigoureuses, de plus ces tests ont eu lieu en RAM pour exclure les goulets d'étranglement. De mon sharepoint vue, l'avertissement mentionné dans la question peut s'appliquer à certaines conditions, mais certainement pas toutes. Ayant partagé avec vous ces résultats assez remarquables, je suis certain que vous êtes d'accord avec moi, que cet avertissement ne devrait probablement pas être pris si au sérieux sur les processeurs modernes avec Hyper-Threading avec la dernière version de VirtualBox. Une chose est sûre: ne me prenez pas pour le mot et testez-le sous vos propres conditions, avant de décider d'appliquer ce paramètre définitivement.

En tant que concepteur OS, je suis entièrement d'accord avec le résultat des mesures. La quantité de conneries produites ailleurs sur le sujet est incroyable.

Voir le nombre de cœurs logiques comme nombre de threads / process parallèles pouvant être exécutés par le matériel. Cela est réalisé en dupliquant, par exemple, les registres et les pointeurs d'instructions d'un cœur de CPU. Le kernel du processeur décide lui-même quel thread (pointeur d'instructions) utiliser. Il décidera d'utiliser l'autre thread car l'instruction du thread courant n'est pas disponible dans le cache et doit être extraite de la memory ou du cache L3 par exemple. Ce mécanisme créera une amélioration potentielle de 10% à 30% des instructions / secondes ou des performances du processeur.

Si vous exécutez une seule application avec un seul thread, vous ne serez pas en mesure de bénéficier de cet avantage, mais si vous exécutez deux applications à forte charge sur un ancien HT Pentium, vous pourrez en retirer les bénéfices. La même chose est vrai bien sûr pour les applications, qui ont plus d'un thread. Mon système Linux count 200 threads, donc certains avantages dépendent de la charge réelle. Toutes ces remarques s'appliquent sans virtualisation.

Virtualbox ne limite que le nombre de threads pouvant être exécutés en parallèle pour chaque machine virtuelle, mais le planificateur de process hôte change le ou les processeurs logiques et donc les processeurs physiques sur lesquels les process VM s'exécutent dynamicment. Si vous exécutez des applications à forte charge sur une machine virtuelle, les cœurs logiques supplémentaires vous apporteront le même avantage de 10% à 30%. La charge peut être une seule application multithread ou un set d'applications différentes.

Sur les systèmes modernes avec VT-x ou AMD-V, il n'y a pas de pénalité de performance pour maximiser le nombre de cœurs logiques, car il n'y a pas non plus de pénalité de performance notable pour exécuter plus de machines virtuelles en même time. Votre limite est la performance de votre puce CPU, vous ne pouvez donc pas rendre les videos sur 3 machines virtuelles en même time sans ralentir chaque machine virtuelle, car elles doivent partager le même processeur physique.

Votre système hôte peut devenir irresponsable si vous restaurez une video sur une machine virtuelle avec tous les cœurs logiques présents, mais vous auriez presque le même problème si vous avez exécuté cette application de rendu sur votre hôte. Au less en VM, vous avez le choix et vous pouvez le résoudre en limitant la charge CPU maximale à 80% -90% ou en réduisant le nombre de coeurs pour cette raison.