Was ist mit dem Prozessor zu tun, wenn nichts zu tun ist?

Published on October 24, 2018

Was ist mit dem Prozessor zu tun, wenn nichts zu tun ist?

Ursprünglicher Autor: Tom Yates
  • Übersetzung
Es wäre vernünftig anzunehmen, dass es für den Kernel recht einfach wäre, nichts zu tun - ist es aber nicht. Auf der Kernel Recipes- Konferenz 2018 sprach Rafael Vysotsky darüber, was Prozessoren tun, wann sie nichts zu tun haben, wie sie den Kern verarbeiten, welche aktuellen Strategien Probleme haben und wie seine jüngste Arbeit am Inaktivitätszyklus die Situation mit dem Stromverbrauch von Systemen verbessert, die nichts tun .

Der Leerlaufzyklus, eines der von Vysotsky unterstützten Kernelsubsysteme, steuert, was die CPU tut, wenn keine Prozesse ausgeführt werden müssen. Vysotsky hat alle Definitionen sehr genau angegeben: CPU ist eine Entität, die Anweisungen aus dem Speicher empfangen und gleichzeitig mit anderen Entitäten in demselben System ausführen kann, die sich mit denselben befassen. Auf dem einfachsten Einzelprozessorsystem mit einem einzelnen Kern ist dieser Kern die CPU. Wenn der Prozessor mehrere Kerne hat, ist jeder dieser Kerne eine CPU. Verfügt jeder der Kerne über mehrere Schnittstellen zur gleichzeitigen Ausführung von Anweisungen - Intel nennt ein solches System " Hyperthreading " -, so ist jeder dieser Threads eine CPU.

Die CPU bleibt im Leerlauf, wenn keine Aufgaben ausgeführt werden müssen. Genauer gesagt, der Linux-Kernel verfügt über mehrere interne Dispatch-Klassen, von denen eine eine spezielle Idle-Klasse ist. Wenn auf dieser CPU in keiner der Klassen, mit Ausnahme der Inaktivitätsklasse, Tasks vorhanden sind, wird die CPU als inaktiv betrachtet. Wenn die Hardware dies nicht zulässt, muss die CPU unbrauchbare Anweisungen ausführen, bis die eigentliche Arbeit erledigt ist. Dies ist jedoch ein äußerst ineffizienter Stromverbrauch, sodass die meisten Prozessoren mehrere Energiesparmodi unterstützen, in die der Kern sie übersetzt, bis sie nützliche Arbeit leisten müssen.

Im Zustand der Untätigkeit kann man nicht einfach ein- oder aussteigen. Es dauert einige Zeit, bis der Prozessor ein- und ausgeht. Wenn Sie in diesen Status eintreten, steigt der Stromverbrauch des aktuellen Status geringfügig an, und wenn Sie ihn verlassen, steigt der Stromverbrauch des Status, in den der Prozessor wechselt. Und obwohl je tiefer der Inaktivitätszustand ist, desto weniger Energie verbraucht der Prozessor, desto höher sind die Kosten für das Betreten und Verlassen solcher Zustände. Dies bedeutet, dass bei kurzen Inaktivitätszeiten die beste Nutzung der Computerressourcen in geringer Inaktivität besteht. Für längere Zeiträume werden die Kosten für einen tieferen Zustand der Untätigkeit durch eine Erhöhung der eingesparten Energiemenge gerechtfertigt. Daher liegt es im Interesse des Kernels, vorherzusagen, wie lange der Prozessor im Leerlauf sein wird, bevor entschieden wird, wie tief der Inaktivitätsstatus benötigt wird.

In diesem Zyklus stellt der Scheduler fest, dass die CPU inaktiv ist, da ihr keine Aufgaben zugewiesen werden müssen. Dann ruft der Scheduler den Regulierer auf, der versucht, die beste Vorhersage für einen geeigneten Untätigkeitszustand zu geben, den Sie eingeben können. Jetzt gibt es im Kern zwei Regler, Menü und Leiter. Sie werden in verschiedenen Fällen verwendet, aber beide versuchen, dasselbe zu tun: den Status des Systems zu überwachen, wenn die CPU in den Inaktivitätsstatus wechselt, und die Zeit, die sie inaktiv verbracht hat. Dies geschieht, um vorherzusagen, wie lange die CPU in diesem Zustand inaktiv ist und welcher Zustand für diese Situation am besten geeignet ist.

Dieser Job wird durch den CPU-Scheduler-Timer besonders kompliziert. Der Scheduler startet diesen Timer, um die Zugriffszeit auf die CPU aufzuteilen: Wenn Sie mehrere Aufgaben auf einem Prozessor ausführen müssen, kann jede von ihnen nur geringfügig ausgeführt und dann in regelmäßigen Abständen zugunsten einer anderen Aufgabe abgelegt werden. Dieser Timer muss nicht auf einer inaktiven CPU ausgeführt werden, da es keine Aufgaben gibt, auf die die CPU aufgeteilt werden muss. Wenn Sie außerdem zulassen, dass der Zeitgeber auf einer inaktiven CPU ausgeführt wird, kann der Controller keine tiefen Inaktivitätszustände auswählen, wodurch die Intervalle begrenzt werden, in denen die CPU inaktiv ist. Daher hat der Scheduler in Kernels bis 4.16 den Timer ausgeschaltet, bevor er den Controller aufrief. Als die CPU durch einen Interrupt aufgeweckt wurde, entschied der Scheduler, ob zur Ausführung des Tasks erforderliche Tasks vorhanden waren, und startete den Timer neu, falls vorhanden.

Wenn der Regler eine lange Leerlaufzeit vorhersagt und diese Zeit sich als sehr lang herausstellt, gewinnt der Regler: Die CPU wird in einen Zustand tiefer Inaktivität versetzt, und Energie wird gespart. Wenn der Regler jedoch eine lange Wartezeit vorhersagt und diese sich als kurz herausstellt, verliert der Regler, da sich die Kosten für das Eingehen einer tiefen Untätigkeit nicht auszahlen, indem er in einer kurzen Zeit der Inaktivität Energie spart. Schlimmer noch, wenn der Regler eine kurze Zeit der Inaktivität vorhersagt - dann „verliert“ er unabhängig von der Dauer der Ausfallzeit: Wenn die Zeit lang war, verpasste er die Gelegenheit zu sparen, und wenn sie kurz war, wurden die Kosten für das Stoppen und Neustarten des Timers verschwendet. Mit anderen Worten, da Ressourcen für das Stoppen und Starten des Timers aufgewendet werden, macht es keinen Sinn, ihn zu stoppen.

Wyssotski beschloss, die Arbeit des Reglers zu ändern, kam jedoch zu dem Schluss, dass das Hauptproblem darin besteht, dass der Timer angehalten wird, bevor der Regler aufgerufen wird, dh bevor der empfohlene Ruhezustand bekannt wird. Er gab den Inaktivitätszyklus in Kernel 4.17 zurück, sodass die Entscheidung zum Stoppen des Timers getroffen wurde, nachdem der Regulierer seine Empfehlung herausgegeben hatte. Wenn er ein langes einfaches vorausgesagt hat, stoppt der Timer, um die CPU nicht vorzeitig zu wecken. Wenn angenommen wird, dass die Leerlaufzeit kurz ist, wird der Timer verlassen, um bei Ausfällen keine Ressourcen zu verschwenden. Dies bedeutet, dass der Timer auch die Sicherheitsfunktion ausführt, die die CPU weckt, wenn sie länger als vorhergesagt einfach ist, und dem Regler eine zweite Chance für die richtige Entscheidung gibt.

Wenn eine inaktive CPU durch einen Interrupt aufwacht, sei es ein nicht gestoppter Timer oder ein anderes Ereignis, entscheidet der Scheduler sofort, ob sie arbeitet. Wenn es Arbeit gibt, wird der Timer bei Bedarf neu gestartet. Wenn nicht, wird der Controller aufgerufen. Da dies bedeutet, dass der Controller jetzt aufgerufen werden kann und wenn der Timer läuft und wenn er nicht funktioniert, muss der Controller aufgerufen werden, um dies zu berücksichtigen.

Nach Prüfung der Gewinn- und Verlusttabelle glaubt Wyssozki, dass die von ihm vorgenommenen Änderungen das Bild verbessern werden. Bei der Vorhersage einer langen Inaktivität stoppt der Timer immer noch, sodass sich hier nichts ändert. Wir gewinnen, wenn die Wartezeit lang ist, und verlieren, wenn sie kurz ist. Wenn jedoch eine kurze Ausfallzeit vorhergesagt wird, gewinnen wir: Wenn sich die Ausfallzeit als kurz herausstellt, sparen wir beim Stoppen und Starten des Timers, und wenn sie lang ist, weckt uns der nicht gestoppte Timer und ermöglicht eine weitere Vorhersage.


Da die Spieltheorie nicht als vollwertiger Ersatz für die reale Situation dienen kann, testete Wyssotski diesen Ansatz auf einer Vielzahl von Systemen. Die obige Grafik ist typisch für alle getesteten Systeme. Es zeigt die Abhängigkeit des Energieverbrauchs von der Zeit eines inaktiven Systems. Die grüne Linie ist der alte Inaktivitätszyklus, die rote ist der neue. Mit dem neuen Energieverbrauchsschema ist es zudem vorhersehbarer. Nicht alle getesteten CPUs hatten eine so große Lücke zwischen den Zeilen, aber sie zeigten alle eine flache rote Linie unter ungleichmäßigem Grün. Wie Vysotsky sagte, sagt dieses neue Schema seltener kurze Inaktivitätsperioden voraus, aber häufiger stellt sich heraus, dass es in Bezug auf ihre kurze Dauer richtig ist.

Auf eine Frage des Publikums antwortete Wyssotski, dass diese Arbeit von der Architektur abhänge. Insbesondere wird es von Intel-Prozessoren profitieren, da diese über eine ausreichend große Anzahl von Inaktivitätszuständen verfügen, aus denen der Controller denjenigen auswählen kann, der benötigt wird, wodurch er bei einer korrekten Vorhersage die besten Erfolgschancen hat. Aber auch ARM-Prozessoren werden von der neuen Schaltung profitieren.


Ein Rückgang des Stromverbrauchs um 20% bei Inaktivität mag als geringfügiger Erfolg erscheinen, in Wirklichkeit ist dies jedoch nicht der Fall. Jedes System, das Spitzenlasten gut genug bewältigen möchte, sollte im Normalmodus über eine Leistungsreserve verfügen, die sich bei Inaktivität bemerkbar macht. Die obige Grafik zeigt die Prozessorauslastung für das Jahr auf meinem Server, der E-Mail, Dateitransfer, VPN, NTP usw. verarbeitet. Gelbe Farbe bedeutet einfache Zeit. Einsparung von 20% dieser Energie hätte meinem Versorger gefallen, und für den Planeten wäre es besser.