Dank dem Tipp von Nils und einem netten Artikel habe ich die Lösung gefunden.
Optimieren von ondemand CPU-DVFS-Governor
Der On-Demand-Regler verfügt über eine Reihe von Parametern, die gesteuert werden müssen, wenn er die dynamische Frequenzskalierung (oder DVFS für dynamische Spannungs- und Frequenzskalierung) aktiviert. Diese Parameter befinden sich unter dem sysfs-Baum:/sys/devices/system/cpu/cpufreq/ondemand/
Einer dieser Parameter ist up_threshold was, wie der Name schon sagt, ein Schwellenwert ist (Einheit ist % der CPU, ich habe jedoch nicht herausgefunden, ob dies pro Kern oder zusammengeführte Kerne ist), oberhalb dessen der On-Demand-Governor einsetzt 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 zu einer Konfigurationsdatei hinzufügen, die während des Bootens gelesen wird, wie /etc/init.d/rc.local auf Ubuntu.
Ich habe herausgefunden, dass meine Gast-VM, obwohl sie viel CPU (80-140 %) auf dem Host verbrauchte, die Last auf beide Kerne verteilte, sodass kein einzelner Kern über 95 % lag, was zu meiner Verzweiflung die CPU war bei 800 MHz bleiben. Mit dem obigen Patch ändert die CPU jetzt dynamisch ihre Frequenz pro Kern viel schneller, was meinen Anforderungen besser entspricht. 50 % scheinen ein besserer Schwellenwert für meine Gastnutzung zu sein, Ihre Laufleistung kann variieren.
Überprüfen Sie optional, ob Sie HPET verwenden
Es ist möglich, dass einige Anwendungen, die Timer falsch implementieren, von DVFS betroffen sind. Dies kann ein Problem in der Host- und/oder Gastumgebung sein, obwohl der Host einen komplizierten Algorithmus haben kann, um zu versuchen, dies zu minimieren. Moderne CPUs haben jedoch neuere TSC (Time Stamp Counter), die unabhängig von der aktuellen CPU-/Core-Frequenz sind, das sind:konstant (constant_tsc), invariant (invariant_tsc) oder nonstop (nonstop_tsc), siehe diesen Chromium-Artikel über TSC-Resynchronisation für weitere Informationen zu jedem. Wenn Ihre CPU also mit einem dieser TSC ausgestattet ist, müssen Sie HPET nicht erzwingen. Um zu überprüfen, ob Ihre Host-CPU sie unterstützt, verwenden Sie einen ähnlichen Befehl (ändern Sie den grep-Parameter auf die entsprechende CPU-Funktion, hier testen wir auf die Konstante TSC):
$ grep constant_tsc /proc/cpuinfo
Wenn Sie keinen dieser modernen TSC haben, sollten Sie entweder:
- Aktives HPET, dies wird nachfolgend beschrieben;
- Verwenden Sie CPU DVFS nicht, wenn Sie Anwendungen in der VM haben, die auf präzises Timing angewiesen sind, 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, vs. HPET befinden sich auf dem Motherboard) und sind möglicherweise nicht präzise (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 schlau genug, den besten verfügbaren Timer zu verwenden, es wird sich zuerst auf den TSC verlassen, aber wenn es sich als zu unzuverlässig erweist, wird es den HPET-Timer verwenden. Dies funktioniert gut auf Host-Systemen (Bare-Metal), aber da nicht alle Informationen ordnungsgemäß vom Hypervisor exportiert werden, ist dies eine größere Herausforderung für die Gast-VM, um 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!
Nachfolgend finden Sie Informationen zum Konfigurieren und/oder Aktivieren von HPET unter Linux und FreeBSD.
Linux-HPET-Konfiguration
HPET, oder High Precision Event Timer, ist ein Hardware-Timer, den Sie seit 2005 in den meisten handelsüblichen PCs finden können. Dieser Timer kann von modernen Betriebssystemen effizient verwendet werden (Linux-Kernel unterstützt ihn seit 2.6, stabile Unterstützung auf FreeBSD seit der letzten Version 9.x wurde aber in 6.3 eingeführt), um für die CPU-Energieverwaltung ausnahmslos ein konsistentes Timing bereitzustellen. Es erlaubt auch einfachere Tick-lose Scheduler-Implementierungen zu bauen.
Grundsätzlich ist HPET wie eine Sicherheitsbarriere, die selbst dann, wenn der Host DVFS aktiviert hat, die Host- und Guest-Timing-Ereignisse weniger beeinflusst.
Es gibt einen guten Artikel von IBM zum Aktivieren von HPET, in dem erklärt wird, wie Sie überprüfen können, welche 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
Prüfen des aktuell aktiven Timers:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
Eine einfachere Möglichkeit, die Verwendung von HPET zu erzwingen, wenn Sie es verfügbar haben, besteht darin, Ihren Bootloader so zu ändern, dass er Sie auffordert, es zu aktivieren (seit Kernel 2.6.16). Diese Konfiguration ist von der Distribution abhängig, also beziehen Sie sich bitte auf Ihre eigene Distributionsdokumentation, um sie richtig einzustellen. Sie sollten hpet=enable aktivieren oder clocksource=hpet in der Kernel-Startzeile (dies hängt wiederum von der Kernel-Version oder -Distribution ab, ich habe keine zusammenhängenden Informationen gefunden).
Dadurch wird sichergestellt, dass der Gast den HPET-Timer verwendet.
Hinweis:Auf meinem Kernel 3.5 scheint Linux den hpet-Timer automatisch zu übernehmen.
FreeBSD-Gast-HPET-Konfiguration
Unter FreeBSD kann man prüfen, welche Timer verfügbar sind, indem man Folgendes ausführt:
sysctl kern.timecounter.choice
Der aktuell gewä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 es unterstützt. Für Linux-Gäste bevorzugen sie jedoch die andere automatisch exportierte Uhr, nämlich kvm-clock (eine paravirtualisierte Version des Host-TSC). Einige Leute 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 zum Gast, und in der GUI gibt es dazu keine Option. 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 dazu zwingen können, die HPET-Uhr als Quelle zu verwenden.
Es ist nicht der Gast, der das Upscale auslöst – das muss der Gastgeber tun. Sie müssen also den entsprechenden Trigger-Level 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 ist im Allgemeinen eine bewährte Vorgehensweise, CPU-Skalierung/Drosselung/usw. zu deaktivieren, wenn VMs ausgeführt werden