Virtualbox avec processeur non VT-x et Hyper-Threading

J’ai un Atom D525 qui ne dispose pas de la virtualisation VT-x Intel.
C’est un double coeur avec Hyper-Threading (ici une sorte d’émulation de 4 CPU)

Problème:
Sous virtualbox, il est possible de n’utilser qu’un seul des coeurs sans la virtualisation VT-x.
Dans la pratique, seulement une Thread du processeur est utilisée.
Ainsi l’utilisation maximum du CPU pour virtualbox ne depasse pas 25%.

Solution:
Désactiver l’Hyper-Threading dans le BIOS.
Maintenant l’utilisation maximum du CPU pour virtualbox est passé à 50%. :smiley:

25% de 4 = 1
contre
50% de 2 = 1
Poussons le bouchon. Pour utiliser 100% de la resource CPU, il suffirait de remplacer le processeur à cœurs multiples par un processeur à cœur unique (1/1).

Intuitivement nous dirions que ce serait plus pénalisant qu’avantageux. On peut penser qu’on tire davantage sur la corde en sollicitant un thread sur deux disponibles (1/2) plutôt qu’un thread sur quatre disponibles (1/4).

Nous ne comprenons pas quel est l’interêt de cette «astuce». Quel est le but recherché ? Est-ce profitable ? En quelle mesure ?

C’est sur qu’avec un processeur à un seul coeur et de l’hyper-threading, il vaut mieux garder peu de ressources pour le système hôte.
Mais si on dispose d’au moins deux coeurs et de l’hyper-threading, ET QUE L’ON N’EN DEMANDE PAS TROP AU SYSTEME HÔTE, à mon avis, ça peut éventuellement valoir le coup.

Sans la technologie VT-x, il est impossible de lancer plusieurs machines virtuelles simultanément. (Enfin c’est ce que j’ai constaté avec Virtualbox).

Que je désactive ou pas l’hyper-threading, à la moindre sollicitation du système invité, virtualbox prend toutes les ressources qui lui sont disponible.
Comme je ne sollicite pas trop le système hôte, il dispose toujours de suffisament de ressouces avec ou sans hyper-theading.

Mon but est d’améliorer les performances de la machine virtuelle, et par la même, la vitesse d’exécution des ses tâches.
A savoir mon D525 obtient sur certain benchmark une note d’environ 700 points, ce qui est assez peu. C’est confortable, voir très confortable sur le système hôte (une wheezy), mais pour virtualbox c’est vraiment pas top.

La différence n’est pas flagrante avec ou sans hyper-threading sur mon D525. C’est pénible dans les deux cas.
A première vue, les machines virtuelles semblent, j’ai bien dit semblent, un poil mieux fonctionner, sans hyper-threading.

Je ferais prochainement quelques tests pour voir si c’est vraiment avantageux.

Mon seul intérêt était d’améliorer les performances de la machine virtuelle.
C’est assez frustrant de voir un processeur à 25%, pendant que la machine virtuelle “mouline”.

Après quelques tests et quelques observations, on dirai que la balance penche en faveur de l’hyper-threading.

  1. Des tests de compression d’un fichier avi de 700Mo avec la commande tar:
    Avec hyper-threading: Environ 4 min 31 s
    Sans hyper-threading: Environ 4 min 37 s

  2. Temps que la debian met pour “démonter” les addons de virtualbox
    Avec hyper-threading:
    Environ 45s
    Sans hyper-threading:
    Environ 1 min 05 s

  3. Un test cpu en console trouvé sur internet
    $ sysbench --test=cpu --cpu-max-prime=10000 run

Avec hyper-threading:
Test execution summary:
total time: 68.5638s
total number of events: 10000
total time taken by event execution: 68.3634
per-request statistics:
min: 3.25ms
avg: 6.84ms
max: 18.77ms
approx. 95 percentile: 7.43ms

Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 68.3634/0.00

Sans hyper-threading:
Test execution summary:
total time: 68.6622s
total number of events: 10000
total time taken by event execution: 68.4572
per-request statistics:
min: 2.54ms
avg: 6.85ms
max: 20.09ms
approx. 95 percentile: 7.43ms

Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 68.4572/0.00

  1. Des tests de lecture du disque virtuel

hdparm -t -T /dev/sda

Avec hyper-threading:
/dev/sda:
Timing cached reads: 1416 MB in 1.96 seconds = 721.59 MB/sec
Timing buffered disk reads: 124 MB in 3.04 seconds = 40.79 MB/sec

/dev/sda:
Timing cached reads: 1382 MB in 1.97 seconds = 702.46 MB/sec
Timing buffered disk reads: 130 MB in 3.00 seconds = 43.33 MB/sec

/dev/sda:
Timing cached reads: 1440 MB in 1.96 seconds = 734.96 MB/sec
Timing buffered disk reads: 134 MB in 3.03 seconds = 44.22 MB/sec

Sans hyper-threading:
/dev/sda:
Timing cached reads: 1372 MB in 1.97 seconds = 697.42 MB/sec
Timing buffered disk reads: 122 MB in 3.02 seconds = 40.38 MB/sec

/dev/sda:
Timing cached reads: 1398 MB in 1.97 seconds = 710.81 MB/sec
Timing buffered disk reads: 122 MB in 3.01 seconds = 40.50 MB/sec

/dev/sda:
Timing cached reads: 1436 MB in 1.97 seconds = 730.04 MB/sec
Timing buffered disk reads: 132 MB in 3.04 seconds = 43.36 MB/sec

  1. Un test en écriture sur le disque virtuel

dd bs=1M count=200 if=/dev/zero of=test

Avec hyper-threading:
de 10.4 à 11.5 MB/s

Sans hyper-threading:
Environ 10.8 MB/s

L’hyperthreading consiste à mieux exploiter un processeur en lui faisant exécuter plusieurs taches via une duplication des unités logiques (les coeurs). C’est comme les fils «threads», même données mais processus différents. La gestion du système peut ralentir parfois le bouzin (par exemple si les données d’un processus rentre pile dans la mémoire cache, à deux processus, ça déborde et du coup l’accès mémoire est ralenti, on doit pouvoir trouver un cas où ça ralentit le tout) mais en général le gain est net. Honnètement, je ne vois pas l’intérêt de supprimer l’HT.