Login
Login-Name Passwort


 
Newsletter
Werbung

Do, 2. August 2007, 11:43

Software::Kernel

Suspend und Hibernation im aktuellen Linux-Kernel

Rafael Wysocki hat einen umfassenden Bericht zur aktuellen Situation von Suspend und Hibernation im Linux-Kernel gegeben.

Vor einem Jahr gab es zuletzt einen vergleichbaren Statusbericht von Wysocki. Seither hat sich ständig etwas getan, so dass es nach seinen Angaben kaum möglich war, die Dinge zu dokumentieren.

Zunächst gibt Wysocki eine Erläuterung des Mechanismus hinter der mit CONFIG_PM im Kernel aktivierten Suspend-Unterstützung. Aus der Datei /sys/power/state kann man den aktuellen Zustand entnehmen, der entweder »standby« oder »mem« ist. In letzterem wird weniger Strom verbraucht. Durch Schreiben des entsprechenden Wertes in die Datei kann man das System zu einem Übergang veranlassen. Dieser Übergang kann aus verschiedenen Gründen scheitern, beispielsweise wenn ein Treiber keinen Suspend-Modus unterstützt. In diesem Fall müssen die bis dahin vorgenommenen Aktionen zum Suspendieren rückgängig gemacht werden.

Hibernation, also das Abschalten des Systems nach Schreiben des aktuellen Zustands auf die Festplatte, kann mit der Option CONFIG_SOFTWARE_SUSPEND aktiviert werden. Durch das Schreiben von »disk« in die Datei /sys/power/state wird die Hibernation, auch Suspend to Disk genannt, angestoßen. Auch hier muss alles rückgängig gemacht werden, wenn ein Fehler auftritt. Ein suspendiertes System wird durch Angabe von »resume=[partition]« an der Kernel-Kommandozeile wieder gestartet. In neueren Kerneln kann an jeden Treiber vor und nach dem Suspendieren eine Benachrichtigung gesendet werden, die der Treiber für spezielle Aktionen nutzen kann.

Das Einfrieren von Prozessen während des Suspendierens ist komplex und wird von einem Prozess namens »Freezer« übernommen. Normale Prozesse erhalten ein Signal, der zu einem Systemaufruf führt, in dem sie verbleiben. Kernel-Prozesse müssen selbst auf den Suspend-Wunsch reagieren. Es gibt einige bekannte Probleme mit diesem Code, normalerweise soll er aber funktionieren. Eine Ineffizienz gibt es noch in der Speicherverwaltung, wo während des Suspend der von den Prozessen belegte Speicher verkleinert werden kann. Bei einer großen Zahl von allozierten Objekten lässt die Geschwindigkeit offenbar noch zu wünschen übrig.

Der Suspend-Code verfügt über ACPI-Unterstützung, die standardmäßig eingeschaltet ist. Obwohl laut Wysocki die ACPI-Plattform-Unterstützung prinzipiell optional ist, fahren einige Systeme nicht korrekt aus dem Suspend-Zustand hoch, wenn sie weggelassen wird. Sie kann von den Benutzern jedoch abgeschaltet werden. Der Code folgt nicht vollständig der ACPI-Spezifikation, und Wysocki macht keine Angaben darüber, ob sich das ändern lässt.

Der Bericht erklärt anschließend die Einzelheiten des Suspend für einzelne Geräte. Hier sieht der Autor als derzeitiges Hauptproblem, dass für Suspend und Hibernate die gleichen Callbacks verwendet werden. Die Treiber können zwar unterscheiden, ob Suspend oder Hibernate gewünscht ist, doch wenige tun dies tatsächlich. Dies erzeuge unnötige Aktionen, so sei es bei Hibernate normalerweise nicht nötig, die Geräte in einen Stromsparmodus zu bringen, da sowieso ausgeschaltet wird.

Ein weiteres Problem sind mobile Speichergeräte. Suspend bewirkt in der Regel einen Abbruch der Verbindung zum Gerät, was im schlimmsten Fall zu Datenverlust führen kann, wenn das Gerät gemountet ist. Probleme gibt es auch bei vielen Grafikadaptern, hier wird jedoch als Lösung vorgeschlagen, das Suspendieren und Wiederherstellen einem Tool zu überlassen, das als Benutzerprozess läuft. Beim Erstellen des Speicherabbilds für die Hibernation gibt es ein anderes Problem, da dieser Vorgang bis zu 50% des verfügbaren RAMs benötigt. Wysocki bezeichnet dies als ernsthafte Einschränkung, die jedoch offenbar in erster Linie die Geschwindigkeit beeinträchtigt, nicht den Vorgang an sich.

Desweiteren gibt es eine Schnittstelle zu den Benutzerprozessen, die es ermöglichen soll, visuelle Rückmeldungen zum Hibernate-Vorgang zu geben. Damit wird es auch möglich, gleichzeitig ins RAM und auf die Festplatte zu suspendieren (Suspend-to-both) und, falls beispielsweise der Akku leer läuft, die Wiederherstellung von der Festplatte zu starten.

Der Artikel schließt mit einem Ausblick auf die zukünftige Entwicklung. Die beschriebenen Probleme sollen korrigiert werden. Daneben ist auch eine Integration mit dem außerhalb des Kernel gepflegten TuxOnIce (früher Suspend2) von Nigel Cunningham, das mehr Features aufweisen soll, denkbar. Wysocki will verstärkt daran arbeiten, die besten Features von TuxOnIce zu übernehmen.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung