Beobachtung:
Ich habe einen HP Server mit einer AMD Dual-Core-CPU (Turion II Neo N40L), die Frequenzen von 800 bis 1500 MHz skalieren kann. Die Frequenzskalierung funktioniert unter FreeBSD 9 und unter Ubuntu 12.04 mit dem Linux-Kernel 3.5. Wenn ich FreeBSD 9 jedoch in eine KVM-Umgebung über Ubuntu lege, funktioniert die Frequenzskalierung nicht. Der Gast (also FreeBSD) erkennt die minimalen und maximalen Frequenzen nicht und skaliert daher nichts, wenn die CPU-Belegung höher wird. Auf dem Host (also Ubuntu) verbraucht der KVM-Prozess zwischen 80 und 140% der CPU-Ressource, aber es findet keine Frequenzskalierung statt. Die Frequenz bleibt bei 800 MHz, obwohl der On-Demand-Governor schnell ausgeführt wird, wenn ich einen anderen Prozess auf derselben Ubuntu-Box ausführe skaliert die Frequenz auf 1500 MHz!

Bedenken und Fragen:
Ich verstehe nicht, wie die CPU möglicherweise virtualisiert ist und ob es an dem Gast liegt, die richtige Skalierung durchzuführen. Müssen einige CPU-Funktionen für den Gast verfügbar gemacht werden, damit dies funktioniert?

Anhang:
Der folgende Versionshinweis zu Red Hat deutet darauf hin, dass die Frequenzskalierung auch in einer virtualisierten Umgebung funktioniert (siehe Kapitel 6.2.2 und 6.2.3). In diesem Hinweis wird jedoch nicht darauf eingegangen, mit welcher Virtualisierungstechnologie dies funktioniert (kvm, xen) , usw.?)

Zur Information cpufreq-infolautet die Ausgabe unter Ubuntu:

$ 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)

Der Grund, warum diese Funktion funktionieren soll, ist: Energie sparen, leiser (weniger heiß) laufen und auch einfach neugierig sein, besser zu verstehen, warum dies nicht funktioniert und wie es funktioniert.

Ich habe die Lösung dank des Tippes von Nils und eines schönen Artikels gefunden .

Optimieren des On-Demand- CPU-DVFS-Reglers

Der On-Demand-Regler verfügt über eine Reihe von Parametern, die gesteuert werden können, wenn die dynamische Frequenzskalierung (oder DVFS für die dynamische Spannungs- und Frequenzskalierung) ausgelöst wird. Diese Parameter befinden sich unter dem sysfs-Baum:/sys/devices/system/cpu/cpufreq/ondemand/

Einer dieser Parameter ist up_threshold, wie der Name schon sagt, ein Schwellenwert (Einheit ist% der CPU, ich habe jedoch nicht herausgefunden, ob dies pro Kern oder zusammengeführte Kerne ist), oberhalb dessen der On-Demand-Regler einschaltet und beginnt, die Frequenz dynamisch zu ändern.

Es ist einfach, es mit sudo auf 50% (zum Beispiel) zu ändern:
sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold"

Wenn Sie root sind, ist ein noch einfacherer Befehl möglich:
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

Hinweis: Diese Änderungen gehen nach dem nächsten Neustart des Hosts verloren. Sie sollten sie einer Konfigurationsdatei hinzufügen, die beim Booten gelesen wird, wie /etc/init.d/rc.localunter Ubuntu.

Ich habe herausgefunden, dass meine Gast-VM, obwohl sie viel CPU (80-140%) auf dem Host verbrauchte, die Last auf beide Kerne verteilte, so dass kein einzelner Kern über 95% lag, daher war die CPU zu meinem Ärger bei 800 MHz bleiben. Mit dem obigen Patch ändert die CPU die Frequenz pro Kern dynamisch viel schneller, was meinen Anforderungen besser entspricht. 50% scheinen ein besserer Schwellenwert für die Nutzung durch meine Gäste zu sein. Ihr Kilometerstand kann variieren.

Überprüfen Sie optional, ob Sie HPET verwenden

Es ist möglich, dass einige anwendbare, die Timer falsch implementieren, von DVFS betroffen sind. Dies kann ein Problem in der Host- und / oder Gastumgebung sein, obwohl der Host über einen komplizierten Algorithmus verfügen kann, um dies zu minimieren. Moderne CPUs verfügen jedoch über neuere TSC (Time Stamp Counter), die unabhängig von der aktuellen CPU- / Kernfrequenz sind. Dies sind: konstant (constant_tsc), invariant (invariant_tsc) oder nonstop (nonstop_tsc). Weitere Informationen finden Sie in diesem Chromium-Artikel zur TSC-Resynchronisation Weitere Informationen zu jedem. Wenn Ihre CPU mit einem dieser TSC ausgestattet ist, müssen Sie HPET nicht erzwingen. Verwenden Sie einen ähnlichen Befehl, um zu überprüfen, ob Ihre Host-CPU sie unterstützt (ändern Sie den grep-Parameter in die entsprechende CPU-Funktion, hier testen wir die konstante TSC):

$ grep constant_tsc /proc/cpuinfo

Wenn Sie keinen dieser modernen TSC haben, sollten Sie entweder:

1. Aktives HPET, das wird hier nachfolgend beschrieben;
2. Verwenden Sie CPU DVFS nicht, wenn Sie Anwendungen in der VM haben, die auf einem präzisen Timing basieren, das von Red Hat empfohlen wird .

Eine sichere Lösung besteht darin, HPET-Timer zu aktivieren (siehe unten für weitere Details). Sie sind langsamer abzufragen als TSC-Timer (TSC befinden sich in der CPU, HPET im Motherboard) und haben möglicherweise keine genaue Genauigkeit (HPET> 10 MHz; TSC) oft der maximale CPU-Takt), aber sie sind viel zuverlässiger, insbesondere in einer DVFS-Konfiguration, in der jeder Kern eine andere Frequenz haben könnte. Linux ist klug genug, um den besten verfügbaren Timer zu verwenden. Es wird zuerst auf dem TSC basieren, aber wenn es zu unzuverlässig ist, wird es den HPET verwenden. Dies funktioniert gut auf Hostsystemen (Bare-Metal-Systemen). Da jedoch nicht alle Informationen vom Hypervisor ordnungsgemäß exportiert wurden, ist dies für die Gast-VM eine größere Herausforderung, sich schlecht verhaltende TSC zu erkennen. Der Trick besteht dann darin, die Verwendung von HPET im Gast zu erzwingen, obwohl Sie den Hypervisor benötigen würden, um diese Taktquelle den Gästen zur Verfügung zu stellen!

Im Folgenden finden Sie Informationen zum Konfigurieren und / oder Aktivieren von HPET unter Linux und FreeBSD.

Linux HPET Konfiguration

HPET oder hochpräziser Ereignis-Timer ist ein Hardware-Timer, den Sie seit 2005 auf den meisten Standard-PCs finden. Dieser Timer kann von modernen Betriebssystemen effizient verwendet werden (der Linux-Kernel unterstützt ihn seit 2.6, stabile Unterstützung unter FreeBSD seit dem neuesten 9.x. wurde jedoch in 6.3 ) eingeführt, um ein konsistentes Timing für die CPU-Energieverwaltung bereitzustellen. Es ermöglicht auch das Erstellen einfacher Scheduler-Implementierungen ohne Ticks .

Grundsätzlich ist HPET wie eine Sicherheitsbarriere, die selbst dann, wenn auf dem Host DVFS aktiv ist, die Timing-Ereignisse von Host und Gast weniger beeinflusst.

Es gibt einen guten Artikel von IBM zum Aktivieren von HPET , in dem erläutert wird, wie Sie überprüfen können, welchen Hardware-Timer Ihr Kernel verwendet und welche verfügbar sind. Ich gebe hier eine kurze Zusammenfassung:

Überprüfen der verfügbaren Hardware-Timer:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Überprüfen des aktuell aktiven Timers:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

Eine einfachere Möglichkeit, die Verwendung von HPET zu erzwingen, wenn es verfügbar ist, besteht darin, den Bootloader so zu ändern, dass er nach der Aktivierung fragt (seit Kernel 2.6.16). Diese Konfiguration ist verteilungsabhängig. Informationen zum richtigen Einstellen finden Sie in Ihrer eigenen Verteilungsdokumentation. Sie sollten hpet=enableoder clocksource=hpetin der Kernel-Boot-Zeile aktivieren (dies hängt wiederum von der Kernel-Version oder -Distribution ab, ich habe keine zusammenhängenden Informationen gefunden).
Stellen Sie sicher, dass der Gast den HPET-Timer verwendet.

Hinweis: Auf meinem Kernel 3.5 scheint Linux den HPP-Timer automatisch zu erfassen.

FreeBSD-Gast-HPET-Konfiguration

Auf FreeBSD kann man überprüfen, welche Timer verfügbar sind, indem man Folgendes ausführt:
sysctl kern.timecounter.choice

Der aktuell ausgewählte Timer kann überprüft werden mit:
sysctl kern.timecounter.hardware

FreeBSD 9.1 scheint HPET automatisch anderen Timer-Anbietern vorzuziehen.

Todo: Wie man HPET auf FreeBSD erzwingt.

Hypervisor HPET-Export

KVM scheint HPET automatisch zu exportieren, wenn der Host dies unterstützt. Für Linux-Gäste wird jedoch die andere automatisch exportierte Uhr bevorzugt, nämlich kvm-clock (eine paravirtualisierte Version des Host-TSC). Einige Personen melden Probleme mit der bevorzugten Uhr. Ihr Kilometerstand kann variieren. Wenn Sie HPET im Gast erzwingen möchten, lesen Sie den obigen Abschnitt.

VirtualBox exportiert die HPET-Uhr standardmäßig nicht in den Gast, und es gibt keine Option, dies in der GUI zu tun. Sie müssen die Befehlszeile verwenden und sicherstellen, dass die VM ausgeschaltet ist. Der Befehl lautet:

./VBoxManage modifyvm "VM NAME" --hpet on

Wenn der Gast nach der obigen Änderung weiterhin eine andere Quelle als HPET auswählt, lesen Sie bitte den obigen Abschnitt, wie Sie den Kernel zwingen, die HPET-Uhr als Quelle zu verwenden.

Es ist nicht der Gast, der die Hochskalierung auslöst - der Host muss dies tun. Sie müssen also den entsprechenden Triggerpegel auf dem Host senken.

Auf dem Host sieht eine kvm-CPU wie ein Prozess aus. Der Skalierungsmechanismus überwacht keine Prozesse, sondern nur den gesamten CPU-Verbrauch.

und es wird im Allgemeinen empfohlen, die CPU-Skalierung / Drosselung / usw. zu deaktivieren, wenn VMs ausgeführt werden