Seite 2: Performance-Zuwachs, anders Schlafen & mehr Speicher ansprechen

Inhaltsverzeichnis

Indirekte Performance-Steigerung durch ORC

Zu einer der wichtigsten Änderungen von 4.14 zählt der ORC Stack Unwinder, der einen weiteren Weg zur Erzeugung besser lesbarer Stacktraces stellt. ORC ist aber keineswegs nur für Entwickler relevant, die bei einem Kernel-Fehler die Namen der Funktionen sehen wollen, über die der Kernel-Code zum Fehlerpunkt gelangt ist. Der neue Analyseweg zum Aufschlüsseln von Call Traces verbessert indirekt auch die Performance bei der alltäglichen Nutzung, denn er braucht keine Frame Pointer, die den Kernel größer und langsamer machen – Fedora, Ubuntu und einige andere Distributionen aktivieren diese aber derzeit nichtsdestotrotz, damit der Frame Pointer Unwinder des Kernels die Call Traces aufschlüsselt. Laut einem Commit-Kommentar kann ein Umstieg auf ORC daher die Performance um 1 bis 3 Prozent steigern; bei besonders Kernel-lastigen Aufgaben können es sogar zwischen 5 und 10 sein, wie auch der Hilfetext zum neuen Unwinder erwähnt.

ORC steht für "Oops Rewind Capability". Das von ihm genutzte Format ist eine vereinfachte Version von DWARF, dem unter Linux meistgenutzten Format für Debugging-Informationen. Beide Formate sind für Binaries gedacht, die im bei Linux gängigen Executable and Linkable Format (ELF) vorliegen.

Die Performance-Steigerung war aber nicht der Hauptgrund zur Entwicklung von ORC; vielmehr wollten die Programmierer einen Stack Unwinder schaffen, der verlässlicher arbeitet als der Frame Pointer Unwinder. Dadurch soll ORC dann letztlich Kernel Live Patching (KLP) robuster und flexibler machen; auch Profiler profitieren vom neuen Ansatz. ORC dürfte aber noch etwas Feintuning brauchen, bevor Distributoren darauf umsteigen. Weitere Details zu diesen und anderen Aspekten von ORC erläutern ein Blog-Eintrag eines Entwicklers, ein LWN.net-Artikel, die Kernel-Dokumentation sowie die Kommentare und Inhalte einiger Commits (u. a. 1, 2, 3, 4, 5).

Viel mehr Speicher ansprechen

Der x86-64-Architekturcode von Linux kann jetzt bis zu 4096 Terabyte (4 Petabyte) Arbeitsspeicher adressieren; Programmen steht sogar ein virtueller Adressraum von 128 Petabyte bereit. Bislang war bei 128 Terabyte virtuellem Adressraum und 64 Terabyte physischem Speicher Schluss – letztgenanntes Limit erreichen einige Hardware-Hersteller gerade mit ihren stärksten Systemen.

Mit aktuellen Prozessoren ist da aber weiter Schluss, denn die zur Adressierung von mehreren Petabyte Arbeitsspeicher zuständigen 5 Level Pages Tables erfordern eine CPU mit einer "LA57" genannten Technik. Laut den Commit-Kommentaren will Intel diese Funktion bei zukünftigen Prozessoren implementieren, anfangs womöglich nur bei einzelnen und teuren Modellen der Xeon-Baureihe. Die bei LWN.net näher erläuterten 5 Level Pages Tables harmonieren derzeit auch noch nicht mit Xen, wohingegen KVM die Technik bereits unterstützt (u. a. 1, 2).

Schlafen wie Android

Einige moderne Notebooks steuern mit 4.14 nicht mehr Suspend-to-RAM (aka STR oder ACPI S3) an, wenn sie diese in den Bereitschaftsmodus schicken. Vielmehr schlafen sie per Suspend-to-Idle, aus dem die Geräte viel schneller aufwachen – zugleich ist die Leistungsaufnahme in diesem Schlafzustand aber höher; daher belastet er den Akku stärker.

Das Ganze betrifft etwa das mit Linux und Windows erhältliche Ultrabook Dell XPS 13 (9360), aktuelle Surface-Notebooks von Microsoft und einige andere Laptops, die zumeist besonders sparsame Prozessoren enthalten und zu den teuren Modellen zählen. [Update 20171110-10:00]Das erwähnte XPS-Ultrabook bleibt vorerst doch außen vor, weil Probleme gefunden wurde.[/Update]. Im Windows-Betrieb wechseln diese Notebooks standardmäßig in einen Stromsparmodus, den Microsoft "Modern Standby" nennt, die Linux-Welt aber Suspend-to-Idle (abgekürzt S2I oder S2Idle). Diesen seit Linux 4.10 unterstützten Schlafzustand nutzt der Kernel bei solchen Notebooks jetzt automatisch. Ein Grund dafür: Hersteller testen vielfach nur den standardmäßig genutzten Schlafmodus mit dem beigepackten Betriebssystem. Bei Geräten mit Modern Standby bleiben dadurch Fehler in den Codepfaden der Firmware unentdeckt, die sich um Suspend-to-RAM kümmern. Dieser traditionell für den Bereitschaftsmodus genutzte Schlafzustand arbeitet auf Suspend-to-Idle-Geräten daher manchmal unzuverlässig oder gar nicht.

Notebooks wachen aus dem Suspend-to-Idle meist sehr schnell auf, sodass sie voll einsatzbereit sind, sobald man das Display aufgeklappt und die Hände auf die Tastatur gelegt hat. Das gelingt, weil Suspend-to-Idle die Komponenten eines Systems lediglich mit den zur Laufzeit nutzbaren Schlafmodi so tief wie möglich schlafen legt. Android-Geräte nutzen solch einen Ansatz schon lange. WLAN-Verbindungen bleiben beim Suspend-to-Idle erhalten; daher muss man auch nicht auf eine Neuanbindung ins Internet warten. Die Leistungsaufnahme im Schlafzustand ist bei diesem Ansatz allerdings höher als beim Suspend-to-RAM. Schließlich erhalten bei ihm nur der Arbeitsspeicher und einige zum Wecken benötigte Komponenten noch Strom.

Windows-Anwender müssen sich mit dem höheren Stromverbrauch im Schlafzustand abfinden, denn Windows wechselt immer in den Schlafzustand, den die Firmware vorgibt. Mit Linux kann man Suspend-to-RAM hingegen auch auf Suspend-to-Idle-Notebooks nutzen: Sie müssen lediglich deep in /sys/power/mem_sleep schreiben, damit das System beim Wechsel in den Bereitschaftsmodus wieder ins Suspend-to-RAM geht. Falls Sie später wieder Suspend-to-Idle verwenden wollen, schreiben Sie s2idle in die Pseudodatei.

Mehr Infos

Dies war ein schrittweise aktualisierter Artikel

Dieser Text wurde mehrfach erweitert, um nach und nach alle wesentlichen Änderungen Linux 4.14 zu beschreiben. Zur jüngst erfolgten Freigabe dieser Kernel-Version haben wir die Abschnitte umsortiert und Abschnitte zu wichtigeren Neuerungen an den Anfang gestellt. Von nun an behält der Text seine jetzige Form. Details zur Versionshistorie des Artikels finden Sie am Artikelende.

Rolle Rückwärts bei der Taktfrequenzangabe in /proc/cpuinfo

Kurz vor Veröffentlichung von Linux 4.14 haben die Entwickler die im Kernel-Log zu Linux 4.13 hervorgehobene Änderung revidiert, durch die /proc/cpuinfo auf x86-Systemen nur noch den Basistakt des Hauptprozessors ausgab (1, 2). Stattdessen liefert die Zeile "cpu MHz" jetzt wieder eine grob berechneten Mittelwert, der von den Taktfrequenzstufen abgeleitet wird, in denen die Prozessorkerne kurz vor der Abfrage liefen. Eine Reihe von Anwendern hat sich dieses Verhalten zurückgewünscht, obwohl der Mittelwert womöglich nicht viel mit der tatsächlich genutzten Frequenz zu tun hat, falls der Prozessor im analysierten Zeitraum zwischen langsamen und schnellen Betriebszuständen hin und her gewechselt hat. Die beiden Änderungen, die das alte Verhalten wieder herstellen, wurden auch in 4.13.12 zurückportiert, damit auch diese Kernel-Serie wieder das frühere Verhalten zeigt.