Un script pour désactiver l'hyperthreading au démarrage de la machine ...
Pour désactiver l'hyperthreading, j'inclus un script sur la machine /etc/rc.local. Il n'est pas extrêmement propre, mais il est facile à installer, indépendamment de l'architecture du processeur et devrait fonctionner sur n'importe quelle distribution Linux moderne.
nano /etc/rc.local
# place this near the end before the "exit 0"
for CPU in /sys/devices/system/cpu/cpu[0-9]*; do
CPUID=$(basename $CPU)
echo "CPU: $CPUID";
if test -e $CPU/online; then
echo "1" > $CPU/online;
fi;
COREID="$(cat $CPU/topology/core_id)";
eval "COREENABLE=\"\${core${COREID}enable}\"";
if ${COREENABLE:-true}; then
echo "${CPU} core=${CORE} -> enable"
eval "core${COREID}enable='false'";
else
echo "$CPU core=${CORE} -> disable";
echo "0" > "$CPU/online";
fi;
done;
Comment ça marche?
Les informations et les contrôles du noyau Linux sont accessibles sous forme de fichiers dans le répertoire / sys sur les distributions Linux modernes. Par exemple:
/ sys / devices / system / cpu / cpu3
contient les informations et les contrôles du noyau pour le cpu logique 3.
cat / sys / devices / system / cpu / cpu3 / topology / core_id
affichera le numéro de cœur auquel appartient ce cpu logique.
echo "0"> / sys / devices / system / cpu / cpu3 / online
permet de désactiver le cpu logique 3.
Pourquoi ça marche?
Je ne sais pas exactement pourquoi ... mais le système devient plus réactif avec l'hyperthreading (sur mon ordinateur portable i5 et les serveurs Xeon massifs avec plus de 60 cœurs). Je suppose que cela a à voir avec les caches par processeur, l'allocation de mémoire par processeur, l'allocation du planificateur de processeur et les itérations complexes des priorités de processus. Je pense que les avantages de l'hyperthreading sont plus importants que la complexité de la création d'ordonnanceurs cpu qui savent comment l'utiliser.
Pour moi, le problème avec l'hyperthreading est: si je démarre autant de threads gourmands en CPU que j'ai de cœurs logiques, j'aurai des changements de contexte rapides pour les tâches gourmandes en CPU, mais coûteux pour les tâches d'arrière-plan, car l'hyperthreading est totalement consommé par le tâches intensives du processeur. D'un autre côté, si je démarre autant de threads gourmands en CPU que j'ai de cœurs physiques, je n'aurai aucun changement de contexte pour ces tâches et des changements de contexte rapides pour les tâches d'arrière-plan. Cela semble bien, mais les tâches d'arrière-plan trouveront des processeurs logiques gratuits et s'exécuteront presque immédiatement. C'est comme s'ils étaient des performances en temps réel (nice -20).
Dans le premier scénario, l'hyperthreading est uselle, les tâches en arrière-plan utiliseront des commutateurs de contexte coûteux car j'ai optimisé l'hyperthreading avec le traitement normal. La seconde est inacceptable car jusqu'à 50% de ma puissance de processeur est priorisée pour les tâches d'arrière-plan.
Les tâches "intensives en CPU" dont je parle sont les serveurs d'exploration de données et d'autorisation d'intelligence artificielle (mon travail). Rendu Blender dans des ordinateurs bon marché et des clusters (pour esquisser ma future maison).
C'est aussi une conjecture.
J'ai l'impression que c'est mieux, mais ce n'est peut-être pas le cas.
sysbench --num-threads=1 --test=cpu runavec différents threads numériques et HT activés et désactivés indique que la désactivation de HT diminue les performances lorsqu'il existe de nombreux threads, et même s'il n'y a qu'un seul thread, il n'y a aucun avantage à désactiver HT. Je suggère donc de le laisser tel quel: c'est optimal.