Observation:
J'ai un serveur HP avec un processeur dual core AMD (Turion II Neo N40L) qui peut mettre à l'échelle des fréquences de 800 à 1500 MHz. La mise à l'échelle des fréquences fonctionne sous FreeBSD 9 et sous Ubuntu 12.04 avec le noyau Linux 3.5. Cependant, lorsque je place FreeBSD 9 dans un environnement KVM au-dessus d'Ubuntu, la mise à l'échelle des fréquences ne fonctionne pas. L'invité (donc FreeBSD) ne détecte pas les fréquences minimales et maximales et ne modifie donc rien lorsque l'occupation du processeur augmente. Sur l'hôte (donc Ubuntu), le processus KVM utilise entre 80 et 140% des ressources CPU mais aucune mise à l'échelle de fréquence ne se produit, la fréquence reste à 800 MHz, bien que lorsque j'exécute tout autre processus sur la même boîte Ubuntu, le gouverneur à la demande rapidement adapte la fréquence à 1500 MHz!

Préoccupation et question:
je ne comprends pas comment le CPU est peut-être virtualisé, et s'il appartient à l'invité d'effectuer la mise à l'échelle appropriée. Faut-il que certaines fonctionnalités du processeur soient exposées à l'invité pour que cela fonctionne?

Annexe:
La note de publication suivante de Red Hat tend à suggérer que la mise à l'échelle de la fréquence fonctionne même dans un environnement virtualisé (voir les chapitres 6.2.2 et 6.2.3), pensant que la note ne traite pas de la technologie de virtualisation avec laquelle cela fonctionne (kvm, xen , etc.?)

Pour information, la cpufreq-infosortie sur Ubuntu est:

$ cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: powernow-k8
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 8.0 us.
  hardware limits: 800 MHz - 1.50 GHz
  available frequency steps: 1.50 GHz, 1.30 GHz, 1000 MHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 800 MHz and 1.50 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
  cpufreq stats: 1.50 GHz:14.79%, 1.30 GHz:1.07%, 1000 MHz:0.71%, 800 MHz:83.43%  (277433)
analyzing CPU 1:
  driver: powernow-k8
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 8.0 us.
  hardware limits: 800 MHz - 1.50 GHz
  available frequency steps: 1.50 GHz, 1.30 GHz, 1000 MHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 800 MHz and 1.50 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
  cpufreq stats: 1.50 GHz:14.56%, 1.30 GHz:1.06%, 1000 MHz:0.79%, 800 MHz:83.59%  (384089)

La raison pour laquelle je veux que cette fonctionnalité fonctionne est: économiser de l'énergie, courir plus silencieusement (moins chaud) et aussi une simple curiosité pour mieux comprendre pourquoi cela ne fonctionne pas et comment le faire fonctionner.

J'ai trouvé la solution grâce à l'astuce donnée par Nils et à un bel article .

Réglage du gouverneur DVFS CPU à la demande

Le régulateur à la demande dispose d'un ensemble de paramètres pour contrôler quand 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_thresholdcomme son nom l'indique, un seuil (l'unité est% du CPU, je n'ai pas trouvé si c'est par cœur ou cœurs fusionnés) au-dessus duquel le gouverneur à la demande entre en jeu et commence à changer dynamiquement la fréquence.

La changer à 50% (par exemple) en utilisant sudo 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.localsur 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 ne dépassait 95%, donc le CPU, à mon exaspération, était restant à 800 MHz. Maintenant, avec le patch ci-dessus, le CPU change 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.

Facultativement, 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 alambiqué 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 CPU / core actuelle, ce 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 (changez le paramètre grep en fonction 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:

1. HPET actif, cela est décrit ci-dessous;
2. N'utilisez pas le CPU DVFS si vous avez des applications dans la machine virtuelle qui reposent sur un timing précis, qui est celui recommandé par Red Hat .

Une solution sûre consiste à activer les minuteurs 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> 10MHz; TSC souvent l’horloge maximale du processeur) mais ils sont beaucoup plus fiables, en particulier 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 le 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 s'agit plus d'un défi pour la machine virtuelle invitée de détecter un TSC se comportant mal. L'astuce consiste alors à forcer l'utilisation de HPET dans l'invité, bien que vous ayez 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énement de haute précision, est une minuterie matérielle que vous pouvez trouver dans la plupart des PC courants depuis 2005. Cette minuterie peut être utilisée efficacement par les systèmes d'exploitation modernes (le noyau Linux la prend en charge depuis 2.6, la prise en charge stable de FreeBSD depuis la dernière 9.x mais a été introduit en 6.3 ) pour fournir un timing cohérent invariablement à la gestion de l'alimentation du processeur. Il permet également de construire des implémentations de planificateur sans tick plus faciles .

Fondamentalement, HPET est comme une barrière de sécurité qui, même si l'hôte a DVFS actif, les événements de synchronisation hôte et invité seront moins affectés.

Il y a un bon article d'IBM concernant l'activation de HPET , il explique comment vérifier quel minuteur matériel votre noyau utilise et lesquels sont disponibles. Je fournis ici un bref résumé:

Vérification du ou des minuteurs matériels 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 à votre propre documentation de distribution pour la configurer correctement. Vous devez activer hpet=enableou clocksource=hpetsur la ligne de démarrage du noyau (cela dépend à nouveau 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 prendre automatiquement le minuteur hpet.

Configuration HPET invité FreeBSD

Sur FreeBSD, on peut vérifier quels minuteurs 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 préférer automatiquement HPET à un autre fournisseur de minuterie.

Todo: comment forcer HPET sur FreeBSD.

Exportation HPET d'hyperviseur

KVM semble exporter HPET automatiquement lorsque l'hôte le prend en charge. Cependant, pour les invités Linux, ils préféreront l'autre horloge exportée automatiquement qui est kvm-clock (une version paravirtualisée de l'hôte TSC). 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 aucune option pour le faire dans l'interface graphique. Vous devez utiliser la ligne de commande et vous assurer que la machine virtuelle est hors tension. 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, seulement la consommation globale de CPU.

et il est généralement recommandé de désactiver la mise à l'échelle / limitation / cpu lors de l'exécution de machines virtuelles