Seite 2: Versionsnummer, Geschwindigkeit und Lizenzdurchsetzungstechnik

Inhaltsverzeichnis

Versionsnummer ist nur Kosmetik

Eine der meist diskutierten Neuerungen des nächsten Linux-Kernels ist nur eine kosmetische: Der Nachfolger von Linux 4.20 trägt nicht die Versionsnummer 4.21, sondern die 5.0. Zu sagen hat der Sprung nichts: Die Änderungen sind nicht zahlreicher oder bedeutender als sonst; auch wurden nicht mehr alte Zöpfe abgeschnitten als üblich. Denn wie zuvor bei den Sprüngen von 2.6.39 auf 3.0 und 3.19 auf 4.0 erfolgte auch der jetzige nur, weil Torvalds die zweite Zahl der Versionsnummer zu groß wurde. Oder wie er sagte: "Mir gehen die Finger und Zehen zum Zählen aus."

Geschwindigkeit zurückerobern!

Zu den wichtigsten Neuerungen von Linux 5.0 zählen Optimierungen, durch die Linux 5.0 beim Versenden von UDP-Paketen und Einsatz des Netzwerk-Schnellverarbeitungswegs XDP (Express Data Path) wieder nahezu die Performance erreichen soll, die Linux Ende 2017 erzielt hat. Das ist einigen Änderungen am DMA- und Netzwerkcode (u. a. 1, 2, 3, 4, 5) zu verdanken, die den Overhead des bei Linux 4.15 eingeführten Retpoline erheblich reduzieren – der in Distributionskerneln typischerweise aktiven Technik also, die vor der Anfang 2018 bekannt gewordenen Prozessor-Sicherheitslücke Spectre v2 zu schützen versucht.

Die Linux-Entwickler diskutieren derweil mit "Static Calls" und "Optpolines" (zuvor: Relpolines) zwei weitere Ansätze, um die Einbußen von Retpoline generell zu reduzieren. Noch ist allerdings ungewiss, ob sie die Praxisreife erreichen.

Lizenzkennzeichnung und -Durchsetzungstechnik trifft ZFS on Linux

Für viel Aufsehen sorgte eine Änderung, die zwei von ZFS On Linux (ZOL) verwendete Funktionen entfernt hat und dieses so kaputt gemacht hat. Diese Funktionen waren schon vor Jahren bei größeren Umbauarbeiten der FPU-Infrastruktur abgekündigt worden, weil dabei ein moderneres Interface geschaffen wurde.

Die moderneren Funktionen gibt der Kernel aber nur per EXPORT_SYMBOL_GPL() frei; sie stehen dadurch nur Kernel-Modulen zur Verfügung, die unter einer zur GPL kompatiblen Lizenz stehen. ZOL kann die neuen Funktionen daher nicht nutzen, weil es einer Lizenz unterliegt, die gemeinhin als inkompatibel zur vom Linux-Kernel verwendeten GPL gilt. Die ZOL-Entwickler haben das Problem in ihrem Hauptentwicklungszweig im Februar umschifft. Laut den Entwicklern steigt die CPU-Last dadurch ein wenig; sie erwarten aber keinen sonderlichen Einfluss auf die Geschwindigkeit, solange die CPU nicht besonders schwach ist oder bereits am Anschlag läuft.

Lizenzkennzeichnung und -Durchsetzungstechnik gegen Nvidia

Das Ganze war offenbar keine Absicht der Linux-Entwickler, sondern ein Kollateralschaden bei Aufräumarbeiten. Details dazu liefert die derzeit am Kiosk erhältliche c't 05/2019 im Artikel "Was soll das? – Linux 5.0: Lizenzkennzeichnung trifft Nvidia und ZFS on Linux".

Der Text beschäftigt sich auch mit einigen weiteren und ganz ähnlich gelagerten Anpassungen des neuen Kernels (1, 2). Durch sie gibt der Kernel zwei essenzielle Funktionen für Heterogeneous Memory Management (HMM) von nun an nur noch per EXPORT_SYMBOL_GPL() frei. Solch eine nachträgliche Änderung bei einer Funktionsfreigabe ist schon ein Novum, aber damit nicht genug: Die entsprechenden Änderungen wurden Mitte Januar in aktuelle Stable- und Longterm-Kernel zurückportiert, daher sind sie auch in Linux 4.20.2, 4.19.15 4.14.93, 4.9.150 und neuer zu finden.

Die Kernel-Entwickler werfen proprietären Treibern damit gezielt Knüppel zwischen die Beine; dabei machen sie keinen Hehl daraus, dass sie damit vor allem Nvidia treffen wollen, wie die LWN.net-Artikel "Heterogeneous memory management meets EXPORT_SYMBOL_GPL()" und The proper use of EXPORT_SYMBOL_GPL() zeigen.

Nutzer des proprietären Nvidia-Grafiktreibers brauchen sich aber nicht zu sorgen: Der einsehbare Teil des Kerneltreibers von Nvidia enthält zwar schon ein wenig HMM-Unterstützung, die ist aber noch unvollständig; sie wird standardmäßig nicht eingebaut, daher jucken die Änderungen den Durchschnittsnutzer nicht.

Nvidia wird jetzt aber sehen müssen, ob oder wie es die Technik unterstützt. Diese erleichtert Programmcode die Handhabung von Daten, die mal der eine und mal ein anderer Prozessor eines Systems verarbeitet; das ist etwa zur effizienteren Einbindung von Grafik- und Kryptoprozessoren wichtig, denen jeweils eigener Arbeitsspeicher zur Seite steht. HMM ist derzeit vor allem für High Performance Computing (HPC) oder Machine Learning wichtig, gewinnt aber auch im Massenmarkt an Bedeutung; das seit Linux 4.14 unterstützte HMM ist zudem ein wesentlicher Bestandteil der Heterogeneous System Architecture (HSA), für die AMD und einige andere Prozessorhersteller seit Jahren trommeln.

Flüssigere 3D-Darstellung mit AMDs Open-Source-Treiber

Der für AMDs moderne Grafikprozessoren zuständige Kernel-Grafiktreiber Amdgpu beherrscht jetzt Freesync, das für flüssige 3D-Darstellung sorgt und so Ruckler und Verzögerungen vermeiden hilft (u. a. 1, 2, 3, 4). Das gelingt durch dynamische Anpassung der Bildwiederholrate, daher wird die auf VESA Adaptive Sync aufbauende Technik auch Variable Refresh Rate (VRR) genannt. Zum Freesync-Einsatz ist neben dem neuen Linux-Kernel auch das dieser Tage erwartete Mesa 19.0 nötig, denn erst der darin enthaltene OpenGL-Treiber von AMD weiß die neuen Kernelfunktionen zu nutzen. Auch AMDs Open-Source-Treiber für den X-Server muss die Technik unterstützen, sofern man einen solchen einsetzt. Die Kernel-, OpenGL- und X.org-X-Server-Treiber des von AMD selbst vertriebenen Treiberpakets beherrschen Freesync schon länger. Das Paket ist aber nur auf einige im professionellen Umfeld gängige Linux-Distributionen ausgelegt; deswegen eignet es sich etwa für einige LTS-Releases von Ubuntu, nicht aber für Ubuntu 18.10. Selbst das kürzlich veröffentlichten Ubuntu 18.04.2 wird noch nicht unterstützt.