J'ai trouvé la solution grâce à l'astuce donnée par Nils et un bel article.
Régler le à la demande Gouverneur DVFS du processeur
Le gouverneur à la demande dispose d'un ensemble de paramètres pour contrôler le moment où il déclenche la mise à l'échelle dynamique de la fréquence (ou DVFS pour la mise à l'échelle dynamique de la tension et de la fréquence). Ces paramètres sont situés sous l'arborescence sysfs :/sys/devices/system/cpu/cpufreq/ondemand/
L'un de ces paramètres est up_threshold qui, comme son nom l'indique, est un seuil (l'unité est % du CPU, je n'ai pas trouvé si c'est par cœur ou par cœurs fusionnés) au-dessus duquel le gouverneur à la demande entre en jeu et commence à changer dynamiquement la fréquence.
Pour le changer à 50% (par exemple) en utilisant sudo c'est simple :
sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold"
Si vous êtes root, une commande encore plus simple est possible :
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
Remarque :ces modifications seront perdues après le prochain redémarrage de l'hôte. Vous devez les ajouter à un fichier de configuration qui est lu au démarrage, comme /etc/init.d/rc.local sur Ubuntu.
J'ai découvert que ma machine virtuelle invitée, bien que consommant beaucoup de CPU (80-140%) sur l'hôte, distribuait la charge sur les deux cœurs, donc aucun cœur n'était supérieur à 95%, donc le CPU, à mon exaspération, était rester à 800 MHz. Maintenant, avec le correctif ci-dessus, le processeur modifie dynamiquement sa fréquence par cœur beaucoup plus rapidement, ce qui convient mieux à mes besoins, 50 % semble un meilleur seuil pour mon utilisation en tant qu'invité, votre kilométrage peut varier.
Facultatif, vérifiez si vous utilisez HPET
Il est possible que certaines applications qui implémentent incorrectement des minuteries soient affectées par DVFS. Cela peut être un problème sur l'environnement hôte et/ou invité, bien que l'hôte puisse avoir un algorithme compliqué pour essayer de minimiser cela. Cependant, les CPU modernes ont des TSC (Time Stamp Counter) plus récents qui sont indépendants de la fréquence actuelle du CPU/cœur, ceux-ci sont :constant (constant_tsc), invariant (invariant_tsc) ou non-stop (nonstop_tsc), voir cet article Chromium sur la resynchronisation TSC pour plus d'informations sur chacun. Donc si votre CPU est équipé d'un de ces TSC, vous n'avez pas besoin de forcer HPET. Pour vérifier si votre CPU hôte les prend en charge, utilisez une commande similaire (modifiez le paramètre grep en fonction de la CPU correspondante, ici nous testons la constante TSC) :
$ grep constant_tsc /proc/cpuinfo
Si vous ne possédez pas l'un de ces TSC modernes, vous devez soit :
- HPET actif, ceci est décrit ci-après ;
- N'utilisez pas CPU DVFS si vous avez des applications dans la VM qui reposent sur une synchronisation précise, qui est celle recommandée par Red Hat.
Une solution sûre consiste à activer les temporisateurs HPET (voir ci-dessous pour plus de détails), ils sont plus lents à interroger que ceux TSC (TSC sont dans le CPU, contre HPET sont dans la carte mère) et peut-être pas précis (HPET> 10 MHz; TSC souvent l'horloge CPU max) mais ils sont beaucoup plus fiables surtout dans une configuration DVFS où chaque cœur peut avoir une fréquence différente. Linux est assez intelligent pour utiliser le meilleur temporisateur disponible, il s'appuiera d'abord sur le TSC, mais s'il est jugé trop peu fiable, il utilisera celui de HPET. Cela fonctionne bien sur les systèmes hôtes (bare metal), mais en raison du fait que toutes les informations ne sont pas correctement exportées par l'hyperviseur, il est plus difficile pour la machine virtuelle invitée de détecter un TSC qui se comporte mal. L'astuce consiste alors à forcer l'utilisation de HPET dans l'invité, même si vous auriez besoin de l'hyperviseur pour mettre cette source d'horloge à la disposition des invités !
Vous trouverez ci-dessous comment configurer et/ou activer HPET sous Linux et FreeBSD.
Configuration Linux HPET
HPET, ou minuterie d'événements de haute précision, est une minuterie matérielle que vous pouvez trouver dans la plupart des PC de base depuis 2005. Cette minuterie peut être utilisée efficacement par les systèmes d'exploitation modernes (le noyau Linux le prend en charge depuis la version 2.6, prise en charge stable sur FreeBSD depuis la dernière version 9.x mais a été introduit dans 6.3) pour fournir une synchronisation cohérente invariablement à la gestion de l'alimentation du processeur. Il permet également de créer des implémentations de planificateurs sans tic-tac plus faciles.
Fondamentalement, HPET est comme une barrière de sécurité qui, même si l'hôte a activé DVFS, les événements de synchronisation de l'hôte et de l'invité seront moins affectés.
Il existe un bon article d'IBM concernant l'activation de HPET, il explique comment vérifier quel temporisateur matériel votre noyau utilise et lesquels sont disponibles. Je vous propose ici un bref résumé :
Vérification de la ou des minuteries matérielles disponibles :
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
Vérification de la minuterie active actuelle :
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
Un moyen plus simple de forcer l'utilisation de HPET si vous l'avez disponible est de modifier votre chargeur de démarrage pour demander de l'activer (depuis le noyau 2.6.16). Cette configuration dépend de la distribution, veuillez donc vous référer à la documentation de votre propre distribution pour la définir correctement. Vous devez activer hpet=enable ou clocksource=hpet sur la ligne de démarrage du noyau (cela dépend encore une fois de la version ou de la distribution du noyau, je n'ai trouvé aucune information cohérente).
Cela garantit que l'invité utilise la minuterie HPET.
Remarque :sur mon noyau 3.5, Linux semble récupérer automatiquement le minuteur hpet.
Configuration HPET invité FreeBSD
Sur FreeBSD, on peut vérifier quels timers sont disponibles en exécutant :
sysctl kern.timecounter.choice
La minuterie actuellement choisie peut être vérifiée avec :
sysctl kern.timecounter.hardware
FreeBSD 9.1 semble automatiquement préférer HPET aux autres fournisseurs de minuterie.
À faire :comment forcer HPET sur FreeBSD.
Exportation HPET de l'hyperviseur
KVM semble exporter HPET automatiquement lorsque l'hôte le prend en charge. Cependant, pour l'invité Linux, ils préféreront l'autre horloge exportée automatiquement qui est kvm-clock (une version paravirtualisée du TSC hôte). Certaines personnes signalent des problèmes avec l'horloge préférée, votre kilométrage peut varier. Si vous souhaitez forcer HPET dans l'invité, reportez-vous à la section ci-dessus.
VirtualBox n'exporte pas l'horloge HPET vers l'invité par défaut, et il n'y a pas d'option pour le faire dans l'interface graphique. Vous devez utiliser la ligne de commande et vous assurer que la machine virtuelle est éteinte. la commande est :
./VBoxManage modifyvm "VM NAME" --hpet on
Si l'invité continue de sélectionner une autre source que HPET après la modification ci-dessus, veuillez vous référer à la section ci-dessus pour forcer le noyau à utiliser l'horloge HPET comme source.
Ce n'est pas l'invité qui déclenche la montée en gamme - l'hôte doit le faire. Vous devez donc baisser le niveau de déclenchement correspondant sur l'hôte.
sur l'hôte, un processeur kvm ressemble à un processus. Le mécanisme de mise à l'échelle ne surveille pas les processus, uniquement la consommation globale du processeur.
et il est généralement préférable de désactiver la mise à l'échelle/la limitation du processeur/etc lors de l'exécution de machines virtuelles