Seite 2: Die wichtigsten Neuerungen

Inhaltsverzeichnis

ATA-Trick verspricht längere Akkulaufzeit

Linux 4.15 enthält eine kleine Änderung an den ATA-Treibern, mit der ein Entwickler die Akkulaufzeit Millionen moderner Notebooks signifikant verlängern will. Wie stark, hängt vom Notebook ab – bei besseren Notebooks dürfte im Leerlauf aber schnell eine halbe oder ganze Stunde mehr drin sein. Der Ansatz verspricht darüber hinaus auch, die Leerlauf-Leistungsaufnahme von PCs zu reduzieren. Es sind aber noch Feldtests nötig, bis Linux-Distributionen dieses Sparpotenzial automatisch nutzen.

Das Ganze betrifft die meisten der in den letzten sechs bis sieben Jahren verkauften PCs und Notebooks, die einen Intel-Prozessor mit per SATA angesprochenen Datenträgern kombinieren. Standardmäßig nutzt Linux bei diesen kein AHCI Link Power Management (ALPM), obwohl das den Stromverbrauch von SATA-Verbindungen bei Untätigkeit signifikant reduzieren kann. Aber nicht nur das: Wenn alle SATA-Links richtig per ALPM ruhen, können Prozessoren seit der Haswell-Generation (u. a. im Core-i-4000 verbaut) bei Untätigkeit teilweise deutlich tiefer schlafen gehen, weil sich der zugehörige SATA-Controller nicht für Aktivitäten bereithalten muss. Das reduziert die Leerlauf-Leistungsaufnahme abermals, sodass das Aktivieren von ALPM letztlich rund ein oder manchmal sogar zwei Watt spart. Bei sparsamen Notebooks senkt das die Leistungsaufnahme im Leerlauf manchmal um 20 oder 30 Prozent.

Altes Problem rund um ALPM

Diese Problematik ist seit vielen Jahren bekannt und war auch mehrfach Thema in c't. Damit vertraute Anwender aktivieren das von Linux schon länger unterstützte ALPM daher manuell. Manche lassen das Software wie Powertop, TLP und Laptop Mode Tools erledigen, andere stellen über die Dateien /sys/class/scsi_host/host*/link_power_management_policy von max_performance auf die ALPM aktivierenden Modi min_power oder medium_power um.

Von den großen Linux-Distributionen setzt aber keine solch eine Einstellung automatisch, weil beide Modi laut vereinzelten Berichten zu Abstürzen oder Datenverlust führen können. Als Ursache stehen Hard- oder Firmware-Probleme ganz oben auf der Verdächtigenliste, weil beide Modi das ALPM etwas anders konfigurieren als der Windows-Treiber für die Intel Rapid Storage Technology (IRST). Ein Aspekt dabei ist die Konfiguration des zu ALPM gehörenden Device Initiated Power Management (DIPM). Nach mehreren Jahren hat ein Entwickler das Problem im Frühjahr 2015 mit Patches anzugehen versucht, durch die einer der bisher setzbaren Modi die Hardware samt DIPM so konfigurierte, wie es der IRST-Treiber macht. Aber auch damit gab es Berichte über Datenverlust und Abstürze. Das Vorhaben verlief daraufhin im Sande.

Ein an Fedora arbeitender Red-Hat-Entwickler hat die Patches jetzt aufgegriffen und so überarbeitet, dass der Kernel nun mit med_power_with_dipm einen vierten Modus versteht. Dieser konfiguriert die Hardware mit genau den ALPM-Parametern, die auch der IRST-Treiber setzt. Nachdem der Entwickler und einige Fedora-Mitstreiter die neue Betriebsart auf einigen Notebooks erfolgreich ausprobiert haben, flossen die DIPM-Patches jetzt in Linux 4.15 ein.

ALPM liegt allerdings nach wie vor standardmäßig brach, denn man muss den neuen Modus explizit aktivieren. Das derzeit entwickelte Fedora 28 soll ihn aber von Haus aus nutzen, damit es das Sparpotenzial automatisch ausschöpft, ohne dass Anwender in die Konfiguration eingreifen müssen. Genau wie bei den anderen ALPM-Sparmodi kann dadurch die SATA-Performance minimal sinken, denn der Wiederaufbau einer SATA-Verbindung kostet einige Millisekunden; in der Praxis ist der Performance-Verlust aber so gering, dass er nicht spürbar und typischerweise vernachlässigbar ist.

Fedora 28 soll übrigens auch einige andere Stromsparfunktionen standardmäßig scharf schalten, die der Kernel und die meisten Linux-Distributionen derzeit links liegen lassen. Wenn keine größeren Probleme bei diesen Feldtests auftauchen, dürften andere Distributionen vermutlich nachziehen.

Meilenstein beim Treiber Amdgpu

Linux 4.15 bringt endlich ordentliche Unterstützung für AMDs Vega-GPUs, die auf den Ende Juli eingeführten Radeon-Grafikkarten RX Vega 56 und RX Vega 64 sitzen. Die dafür zuständigen Änderungen verbessern auch den Support für die Raven-GPU des im Oktober angekündigten Ryzen Mobile. Damit nicht genug: Auch die Unterstützung für viele andere moderne Radeon-Karten soll dadurch besser werden, denn mit dem neuen Code unterstützt der Treiber einige bislang brach liegende Techniken zur Monitoransteuerung. Darunter befindet sich der Support für HDMI 2.0 und DisplayPort (DP) 1.4, was für 4K- und 5K-Bildschirme wichtig ist; außerdem unterstützt der Treiber bei vielen der neueren Grafikkarten jetzt endlich HDMI- und DP-Audio.

Kernel-Entwickler sagen NEIN!

Zu verdanken sind diese Fortschritte einer DC (Display Core) genannten Serie von Änderungen, die mit über 800 Patches und mehr als 130.000 hinzugefügten Zeilen einen dicken Brocken darstellt. AMD hat diese Patch-Serie anfangs intern mit dem Ziel entwickelt, einige Kernfunktionen des Codes auch bei den Treibern für andere Betriebssysteme zu verwenden. Dazu enthielt der Code eine Abstraktionsschicht.

Im Frühjahr 2016 hat AMD die damals noch DAL (Display Abstraction Layer) genannte Patch-Sammlung dann veröffentlicht mit dem Ziel, sie bald in Linux zu integrieren. Der für die Grafiktreiber zuständige Kernel-Entwickler Dave Airlie und ein weiterer Kernentwickler winkten aber schnell und sehr deutlich ab: Die Patch-Sammlung entsprach ihren Qualitätsansprüchen nicht. Hauptgrund, vereinfacht gesagt: Ihnen gefiel die Abstraktionsschicht zwischen den Kernfunktionen des DC-Codes und dem Atomic-Framework des Kernels nicht, welches als Basis für moderne Kernel-Grafiktreiber gedacht ist. Erschwerend kam hinzu, dass DAL einige Funktionen reimplementierte, die das Atomic-Framework und andere Teile des Kernels bereits enthalten; einige Codeteile boten zudem Features, die besser im treiberunabhängigen Kernel-Code aufgehoben wären, damit auch andere Treiber diese Funktionen nutzen können und nicht reimplementieren müssen.

Airlie & Co. sahen daher viel Code von DAL eher als Ballast an, der Pflege und Weiterentwicklung des Linux-Kernels unnötig verkompliziert hätte. Nach anfänglicher Gegenwehr und vielen Diskussionen haben die AMD-Entwickler das eingesehen und begonnen, die Patch-Sammlung anzupassen, damit sie die gestellten Anforderungen besser erfüllt. Das ist nach 18 Monaten jetzt weitgehend der Fall, wie Airlie im Commit-Kommentar zur DC-Aufnahme erläutert – es gibt aber durchaus noch einiges zu verbessern, wie eine Todo-Liste zeigt.

Vorteile auch für viele ältere Radeon-Karten

Durch die Aufnahme für 4.15 ist der Treiber Amdgpu nun auch mit Vega-Chips in der Lage, Bildschirme anzusteuern – bislang ließ sich die bei Linux 4.12 integrierte Vega-Unterstützung nur zum Rechnen oder Rendern mit Vega-GPUs nutzen.

Der DC-Code unterstützt aber nicht nur die für die Bildschirmausgänge zuständige DCE (Display Controller Engine) von Vega- und Raven-GPUs, sondern auch die der direkten Vorgänger bis hin zum DCE8 (Sea Islands & Kaveri). Amdgpu nutzt DC bei älteren GPUs aber derzeit nur, wenn sie den Treiber durch Angabe des Kernel-Bootparameters amdgpu.dc=1 explizit dazu auffordern. Das ist etwa für Polaris-GPUs interessant, die auf den aktuellen Radeon-RX-Grafikkarten 460 bis 480 und 540 bis 580 sitzen. Durch DC können diese dann nämlich auch Audio via HDMI oder DisplayPort (DP) weiterleiten, was der Treiber bei älteren GPUs auch ohne DC beherrscht. Durch DC unterstützt er zudem Techniken wie DP 1.4, DP Multistream Transport (MST) und HDMI 2.0, die zur ordentlichen Ansteuerung besonders hochauflösender Monitore wichtig oder nötig sind; HDMI 2.0 erlaubt etwa, 4K-Monitore mit 60 Hertz oder mehr anzusteuern, damit der Bildaufbau flüssiger erfolgt als bei 30 Hertz. Der Kernel-Parameter ist aber nur eine Übergangsmaßnahme: Nach Feldtests soll er verschwinden, damit Amdgpu den DC-Code auch bei älteren GPUs automatisch nutzt, damit die erwähnten Features von Haus aus funktionieren.

Beim Einsatz von DC greift Amdgpu nun auch auf die Atomic-Infrastruktur zurück, die Intels Treiber seit 4.12 nutzt; sie macht unter anderem die Monitor-Konfiguration verlässlicher und ermöglicht eine bessere Synchronisation der Bildausgabe, was für Bedienoberflächen von Desktop und Spielen wichtig ist. AMDs DC legt ferner Grundlagen zur Unterstützung von VESA Adaptive-Sync, dessen Implementation bei AMD als Freesync läuft; ähnlich wie Nvidias G-Sync kann diese Technik die Bildwiederholrate von Monitoren dynamisch anpassen, um Verzögerungen und Ruckler in Spielen zu vermeiden.

Stellungnahme gegen Closed-Source-Treiber

In der Kernel-Dokumentation findet sich nun ein Statement, mit dem sich einige Entwickler des Linux-Kernels klar gegen proprietäre Linux-Treiber aussprechen. Ihnen zufolge seien Kernel-Module oder Treiber schädlich und unerwünscht, die Closed-Source-Code enthalten. Solche hätten sich wiederholt als nachteilig für Nutzer, Firmen und das Linux-Ökosystem erwiesen. Firmen, die Closed-Source-Module verteilen, würden ihre Kunden zwingen, zentrale Vorteile von Linux aufzugeben oder andere Anbieter zu wählen. Der Text endet mit einem Appell an Hardware-Hersteller, Linux-Kunden mit quelloffenem Kernel-Code zu unterstützen.

Rund 175 Entwickler haben diese Stellungnahme unterzeichnet, die seit 2008 existiert und mit Rückendeckung der Linux Foundation veröffentlicht wurde. Jetzt floss sie in die Linux-Quellen ein, denn auf den Webseiten der Interessenvereinigung war sie nur schwer zu finden und zog zudem gelegentlich um; außerdem hatten selbst treibende Kräfte den Schreibzugang verloren. Von nun an können Entwickler das Dokument viel leichter unterschreiben: Sie müssen lediglich einen Kernel-Patch einreichen, der ihre Signatur einfügt.

Zu den Unterzeichnern zählt eine Reihe zentraler Linux-Entwickler, darunter Dave Airlie, Jens Axboe, Arnd Bergmann, Mauro Carvalho Chehab, Thomas Gleixner, Takashi Iwai, Greg Kroah-Hartman, Ingo Molnar, Andrew Morton und Theodore Tso. Linus Torvalds ist allerdings nicht dabei.

Endlich modernere CPU-Ressourcenregelung

Der zur Regelung des Ressourcenverbrauchs zuständige Cgroup-Code bringt nun einen Cgroup v2 Controller mit, der die von Prozessen einer Gruppe verwendbare CPU-Zeit limitieren kann. Der floss nach jahrelangen Streitigkeiten um die Frage ein, wie das Cgroup-Interface der zweiten Generation denn Threads handhaben soll. Diese wurden mit dem in Linux 4.14 eingeflossenen Cgroup v2 Thread Support endlich gelöst, auf die der neue CPU-Controller zurückgreift.