Die Neuerungen von Linux 4.10

Inhaltsverzeichnis

Nach zehn Wochen Entwicklungszeit hat Linus Torvalds den Linux-Kernel 4.10 veröffentlicht. Er bringt eine neue Möglichkeit, die Grafikbeschleunigung eines Systems auch in virtuellen Maschinen nutzen zu können. Die Grundlage dazu legt eine neue Infrastruktur, die Hardware-Komponenten teilweise oder nahezu komplett an Virtual Machines (VM) überstellen kann, ohne dass es die Sicherheit des Wirtsystems gefährdet oder die Performance erheblich reduziert. Der Kernel-Grafiktreiber für Intel-GPUs kann diese Funktion bereits nutzen, um Teile eines Grafikprozessors an VMs zu überstellen; die Treiber für AMD- und Nvidia-GPUs sollen bald ähnliches lernen.

Virtuelle Geräte, die echte Hardware enthalten

Die Grundlagentechnik zur Hardware-Überstellung an VMs ist das "Mediated Device Interface" (u.a. 1, 2). Mit ihm kann ein Kernel-Treiber auf dem Host ein "Mediated Device" (Mdev) erzeugen. Ein solches kann dann Qemu, das bei der Virtualisierung mit KVM und Xen involviert ist, einer VM zuteilen. Dessen Betriebssystem kann das Mdev ähnlich ansprechen wie andere für die VM emulierte Hardware. Mdevs müssen aber keine komplett virtuelle Hardware sein, denn sie können Zugriff auf reale Hardware-Komponenten oder Teilfunktionen davon gewähren. Die Kommunikation mit dem Host-Treiber erfolgt dabei via VFIO (Virtual Function I/O), das wenig Overhead aufweist.

Letztlich lässt sich so aus VMs ohne allzu große Geschwindigkeitseinbußen auf reale Hardware zugreifen. Die auf dem Host eingesetzten Treiber müssen allerdings angepasst werden, um einen Chip oder Teile davon als Mediated Device bereitstellen zu können, ohne die Sicherheit des Systems zu gefährden. Unter den geplanten Treiberanpassungen sind welche, um Nvidias Virtual GPUs (vGPUs) zu unterstützen, das Teile von GeForce-GPUs in VMs nutzbar macht. Mediated Devices sind aber auch für andere Hardware-Komponenten nutzbar. Daher sollen sie beispielsweise auf s390-Systemen bei der Virtualisierung von Channel I/O Devices (aka "CCW devices") zum Einsatz kommen.

Intels Grafiktreiber nutzt Mdevs bereits

Die Kernel-Entwickler haben bei Linux 4.10 auch gleich den Intel-Grafiktreiber angepasst, damit er Mediated Devices nutzen kann, um Teilfunktionen moderner Intels-GPUs performant an VMs zu überstellen. Bislang gelingt damit aber nur ein Headless-Mode, denn Unterstützung zur Bildausgabe ist noch in Arbeit; außerdem erfordert es einen Prozessor aus einer der drei neuesten Generationen (Broadwell/Core i-5xxx und neuer).

Techniken zur Grafikbeschleunigung in VMs​

Intels GVT/KVMGT und vergleichbare Techniken von AMD und Nvidia versprechen die Nutzung von Grafikprozessoren in VMs alltagstauglicher und sicherer zu machen. Zwar gibt es schon länger Wege, um Haupt- oder Zweigrafikkarte des Wirts komplett an VMs zu überstellen ("VGA passthrough"). In einzelnen Konstellationen läuft das auch ganz gut; oft hakt es aber gewaltig, weil sich Mainboard, BIOS, Grafikchip, Treiber oder irgendwas anderes quer stellt. Diese Probleme sind einer der Gründe, warum die bisherigen Ansätze seit Jahren eher ein Nischendasein pflegen.

Weiter verbreitet ist hingegen der von VMware Workstation oder VirtualBox gebotene Ansatz: Diese ermöglichen 3D-Beschleunigung, indem sie der VM einen begrenzten Zugriff auf den Grafikprozessor des Wirts gewähren. Das ist für so manche Aufgaben schnell genug; so richtig schnell ist das aber nicht realisierbar, ohne zugleich Gefahr zu laufen, dass das Gastsystem den Wirt ausspähen oder sogar übernehmen kann. Etwas besser macht es Virgl3d, das Linux 4.4 und neuer ermöglichen. Das Gewährleisten der Sicherheit kostet aber auch hier Performance; außerdem funktioniert die Technik nur für Linux-Gäste.

Das Konzept läuft bei Intel unter dem Oberbegriff Graphics Virtualization Technology (GVT); erste Teile zum Support der Technik flossen schon in Linux 4.8 ein. Diese früher ohne Mediated Devices arbeitende Technik funktioniert prinzipiell sowohl mit KVM als auch mit Xen; Intels Grafiktreiber unterstützt bei 4.10 aber nur die KVMGT genannte Technikvariante, die den Linux-eigenen Hypervisor KVM erfordert (u.a. 1, 2, 3, 4, 5, 6, 7, 8, 9).

Bis GVT/KVMGT alltagstauglich wird, sind aber noch weitere Änderungen nötig: VMs können mit der Technik zwar jetzt Teile der Host-GPU zum Rechnen verwenden, mit ihr aber noch keine Bilder direkt ausgeben. Details dazu liefert Gerd Hoffmann in einem Blog-Eintrag zum Entwicklungsstand von GVT/KVMGT, in dem er auch umreißt, wie man die Technik ausprobieren kann. Dabei erläutert er, wo es derzeit überall noch hakt. Wenig später hat er einen weiteren Blog-Eintrag publiziert, in dem er erste kleine Erfolge bei der Übergabe eines Kernel-Framebuffer-Bildes vom lokalen Gast an den Host via GVT beschreibt.

Ohnehin bleibt abzuwarten, wann das Ganze in Distributionen ohne tiefe Konfigurationseingriffe nutzbar sein wird: Mit dem Host-Kernel, Hypervisor, Qemu, Virtualisierungssoftware und den Grafiktreibern von Wirt und Gast muss nämlich viel Software korrekt zusammenspielen, die von unterschiedlichen Leuten entwickelt wird.

Drosseln für mehr Geschwindigkeit

Anwendungen wie Firefox sollen bei 4.10 nicht mehr so leicht ins Stocken geraten, während der Kernel große Datenmengen schreibt. Das passiert bislang häufiger, wenn man einen USB-Stick zum Linux-Installationsmedium macht. Typischerweise puffert der Kernel dabei viele Daten im Writeback-Cache, um diese dann nach und nach auf den USB-Stick zu schreiben. In dieser Zeit ruckelten Programme wie Firefox teilweise stark, weil sie im Betrieb häufiger kleinere Datenmengen schreiben oder lesen. Das führt zu den Rucklern, denn die Lese- und Schreiboperationen kamen oft erst spät zum Zug, wenn der Kernel parallel mit dem Rausschreiben größeren Datenmengen aus dem Writeback-Cache beschäftigt war. Im dümmsten Fall summierten sich die Latenzen so weit, dass Firefox oder der ganze Desktop vorübergehend unbenutzbar wurden.

Das jetzt in den Block Layer integrierte "Writeback Throttling" vermeidet das, indem es das Leeren des Writeback-Caches beim Anstehen anderer Lese- und Schreiboperationen drosselt, damit letztere früher an der Reihe sind. Tests des Entwicklers zeigen, dass das System dadurch deutlich flüssiger arbeitet, ohne dass es den Durchsatz beim Rausschreiben der Daten signifikant reduziert. Das Ganze ist auch bei Servern wichtig, damit etwa Datenbanken die ihnen gestellten Anfragen mit möglichst geringen Wartezeiten abarbeiten, selbst wenn irgendetwas gerade größeren Datenmengen zum Speichern an den Kernel übergeben hat. Ob der neue Mechanismus greift, hängt aber von der individuellen Konfiguration ab; er wird etwa nicht bei Datenträgern aktiv, bei denen CFQ als I/O-Scheduler verwendet wird und zugleich eine Non-Root-Block-Cgroup konfiguriert ist. Weitere Hintergründe zum Ganzen liefern ein im April erschienener LWN.net-Artikel und die Kommentare einiger Commits (u. a. 1, 2, 3)

Problematische Storage-Konfiguration

Nach den Linux-Inkompatibilitäten einiger Lenovo-Notebooks weist die neue Linux-Version jetzt in den Kernel-Meldungen darauf hin, wenn es NVMe-Datenträger eines Systems nicht ansprechen kann, weil das BIOS die Storage-Adapter auf eine ungeschickte Weise konfiguriert. Betroffen von diesem Problem, über das zahlreiche Medien berichtet haben, ist zumindest das Yoga 900-13ISK2. Nach dem öffentlichen Aufsehen hat Lenovo für dieses Modell ein BIOS-Update freigegeben, das dem BIOS-Setup eine Option spendiert, um den SATA-Controller im AHCI-Modus zu betreiben. Beim regulären BIOS läuft dieser aber nach wie vor immer im RAID-Modus, in dem Linux nicht auf den NVMe-Datenträger des Notebooks zugreifen kann, obwohl Letzterer gar kein Bestandteil eines RAIDs ist.

Lenovo lehnt den Support für dieses "Linux-BIOS" allerdings ab und hat die Option auch nicht in das reguläre BIOS für das Notebook eingepflegt. Anwender, die von der Problematik nicht gehört haben, stoßen daher nach wie vor auf Schwierigkeiten. Außerdem gibt es die Problematik auch bei anderen Notebooks, wobei man sie dort zumeist durch Umstellen von RAID- auf AHCI-Modus aus der Welt schaffen kann. Genau darauf weist der Kernel mit dem Hinweis

Found n remapped NVMe devices.
Switch your BIOS from RAID to AHCI mode to use them

jetzt hin. Danach sollte man daher Ausschau halten, wenn der Linux-Installer die Datenträger eines Notebooks mit NVMe-SSDs nicht erkennt.

Die Entwickler hatten übrigens an Änderungen gearbeitet, durch die der Kernel den Storage-Adapter beim Booten automatisch in einen Modus schalten sollte, der den Zugriff auf die NVMe-SSDs ermöglicht. Der Ansatz erwies sich aber als nicht zuverlässig genug. Die Entwickler entschieden sich daher zur Warnung, damit Anwender immerhin wissen, wo es hakt. Die Kernel-Entwickler haben Intel und dessen Manager im Rahmen der Änderungen für das Dilemma deutlich kritisiert, weil das Unternehmen nicht bei der Entwicklung einer ordentlichen Lösung hilft, nachdem Lenovo das BIOS veröffentlicht hat.

Dies war ein schrittweise aktualisierter Artikel​

Dieser Text wurde mehrfach erweitert, um nach und nach alle wesentlichen Änderungen Linux 4.10 zu beschreiben. Zur jüngst erfolgten Freigabe von Linux 4.10 haben wir die Absätze 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.

Neuer Schlafzustand

Vorwiegend für neue Notebooks relevant ist die neue Sysfs-Datei /sys/power/mem_sleep. Über sie kann man festlegen, in welchen Schlafzustand das System gehen soll, wenn es zum Wechsel in einen solchen aufgefordert wird – etwa vom Anwender über die Desktop-Umgebung oder durch Zuklappen des Notebook-Displays. Dann wechseln Systeme derzeit typischerweise mit ACPI S3 in einen Suspend-to-RAM. Einige neuere Notebooks bieten mit Suspend-to-Idle (gelegentlich auch S2I oder s2idle genannt) einen moderneren Schlafmodus.

Ähnlich wie bei Android-Geräten werden beim Suspend-to-Idle nahezu alle Komponenten eines Systems mit den zur Laufzeit nutzbaren Schafmodi tief schlafen gelegt, sodass nur noch einige Kernfunktionen des Systems arbeiten; darunter die zum Aufwachen benötige Hardware. Die Leistungsaufnahme ist dadurch zwar etwas höher als beim Suspend-to-RAM, bei dem letztlich nur noch der Arbeitsspeicher mit Strom versorgt wird und Prozessor und Board nahezu komplett abgeschaltet werden.

Durch das andere Vorgehen bleiben Netzwerkverbindungen bestehen und das System wacht aus einem Suspend-to-Idle deutlich schneller auf; Notebooks sind dadurch voll einsatzbereit, sobald man das Display aufgeklappt hat. In der Windows-Welt wird das Modern Standby genannt. Einige neuere Notebooks nutzen diesen aus "Connected Standby" hervorgegangenen Schlafzustand schon automatisch. Darunter etwa auch das aktuelle Dell XPS 13, von dem es mit der "XPS 13 Developer Edition" auch eine Modellvariante mit Ubuntu gibt.

Beim Kurztest mit einem solchen Notebook funktionierte Suspend-to-Idle mit einer Vorabversion von Linux 4.10 aber nicht. Daher wurde auch der Plan verworfen, Suspend-to-Idle automatisch zu nutzen, wenn die Firmware es vorgibt. Schuld an den Problemen war unter anderem: Der Kernel konfigurierte keine Geräte, die das System aus dem Schlafzustand aufwecken dürfen. An der Beseitigung dieser Schwachstelle tüfteln die Entwickler bereits, daher dürfte sich die Situation bei Linux 4.11 oder 4.12 bessern.

Schnelleres WLAN

Die Entwickler im Umfeld der Initiative "Make-wifi-fast" haben Umbauten am Ath9k-Treiber vorgenommen, um dessen Performance zu verbessern und die Kommunikation mit Webservern robuster zu machen. Dabei geht es nicht darum, den maximalen Durchsatz zu steigern; vielmehr sollen die Verbindungs-Latenzen deutlich sinken, damit der Datenaustausch schneller erfolgt und nicht so leicht durch Timeouts beendet wird.

Das Ganze wird vornehmlich erreicht, indem starkes Puffern im WLAN-Stack (Treiber, Subsystem, Chip, ...) vermieden wird. Gegen diese auch als "Bufferbloat" bekannte Problematik kämpfen zahlreiche Entwickler seit einigen Jahren bei Routern, Netzwerkkarten, Netzwerktreibern und anderen Stellen; vieles wurde schon verbessert, aber bei der WLAN-Unterstützung von Linux sind zu große Puffer nach wie vor ein Problem. Die Entwickler haben daher schon bei Linux 4.8 einige Umbauten im WLAN-Stack vorgenommen, um Bufferbloat auch hier mittelfristig zu reduzieren oder komplett zu beseitigen. Auf diesen Grundlagen bauen die jetzigen Treiberanpassungen auf.

Vorerst profitieren davon nur Nutzer eines der von Ath9k unterstützten WLAN-Chips von Atheros/Qualcomm. Die Entwickler arbeiten aber bereits an Änderungen, um Bufferbloat beim Ath10k-Treiber zu vermeiden und so dessen Performance zu verbessern. Weitere Details zu den Umbauten und den Problemen, die durch zu extensives Puffern entstehen können, erläutert der LWN.net-Artikel "Making WiFi fast". Dieser berichtet von einem Vortrag, in dem der Vortragende die Probleme von Bufferbloat am Beispiel von Slashdot beschrieb: Ohne größere Verbindungslatenzen habe die Webseite bei Tests in acht Sekunden geladen; bei einer Latenz von einer Sekunde seien es hingegen vier Minuten gewesen.

Netzwerk-Verkehr individuell filtern

Über die neuen "eBPF hooks for cgroups" sollen dafür geschriebene Programme in Zukunft den Netzwerkverkehr filtern können, den einer Control Groups (Cgroups) zugeordnete Prozesse erzeugen oder annehmen (u.a. 1, 2, 3, 4, Beispielcode). Durch dieses Traffic Filtering können Admins etwa direkt für jeden Hintergrunddienst individuell festlegen, auf welchen Ports dieser Daten senden und empfangen kann oder mit welchen IP-Adressen ein Dienst interagieren darf. Zugleich kann der Kernel mit Hilfe der neuen Schnittstelle auch leicht Buch darüber führen, wie viele Daten die Prozesse einer Cgroup erzeugt oder angenommen haben.

Solche Funktionen lassen sich vielfach auch über Paketfilter im Kernel realisieren. Iptables, Nftables & Co. scheren sich allerdings nicht um den Prozess, der die Daten letztlich sendet oder empfängt. Es kann die Wartung erleichtern, die Regeln zusammen mit den Programmen festzulegen, die die Netzwerkdaten verarbeiten. Außerdem kann es flexibler sein: So kann man darüber beispielsweise einer einzelnen Anwendung die Kommunikation mit dem Internet erlauben, zugleich aber leicht unterbinden, dass die Anwendung andere Dienste auf dem Host oder im internen Netz erreicht.

Das Ganze ist aber noch nicht ganz fertig: Die mit dem eBPF (extended Berkeley Packet Filter) ausgeführten Filterprogramme sollen erst mit einer eBPF-Erweiterung effizient arbeiten, die frühestens bei 4.11 folgen soll. Details hierzu und Hintergründe zur Technik im Allgemeinen liefern die LWN.net-Artikel "Network filtering for control groups" und "Last-minute control-group BPF ABI concerns".

Netzwerk: Programm-eigene Routen, Schnellstraße, Nftables, …

Netzwerk-Routen lassen sich nicht mehr nur systemweit, sondern für jeden Nutzer individuell festlegen (u. a. 1, 2). Der Kernel von Android bot eine solche Funktion schon länger; Google-Entwickler haben den dafür zuständigen Code jetzt überarbeitet und in den offiziellen Kernel eingebracht.

Der bei Linux 4.8 integrierte "Express Data Path" (XDP), der den normalen Netzwerk-Stack umgeht und so Overhead vermeidet, kann Daten jetzt auch über Virtio-Net weiterreichen (u. a. 1, 2). Dadurch können XDP-Programme die an der Netzwerkkarte eintrudelnden Daten beispielsweise direkt an eine Virtual Machine (VM) weitergeben, damit das dort laufende Betriebssystem sie ohne viel Overhead erhält. Wo diese Technik zum Einsatz kommt und wie effizient sie arbeitet, wird sich zeigen müssen, denn es gibt bereits einige Wege, um Netzwerkdaten mit wenig Overhead an VMs durchzureichen.

Der Nftables-Code des Kernels kann nun eine "FIB Expression" nutzen, das eine ähnliche Funktion stellt wie die Addrtype- und Rp_filter-Matches von Xtables. Ferner kann Nftables durch eine neue "Routing Expression" nun Netzwerkpakete für ein bestimmtes Subnetz fallen lassen, falls diese nicht über einen bestimmten Router eingelaufen sind. Neu sind auch Stateful Objects, die Quotas und Accounting ermöglichen. Mit solchen Detailverbesserungen schließt der Funktionsumfang von Nftables noch etwas weiter zu dem der Iptables-Welt auf, die Nftables zu beerben versucht.

Unter zahlreichen weiteren Änderungen am Netzwerksubsystem waren ferner einige, die die UDP-Performance unter Last steigern (u. a. 1, 2). Außerdem lässt sich der BPF nun auch für die "Lightweight Tunnel Infrastructure" nutzen (u. a. 1).

Writeback-Cache für Software-RAID-5

Der Kernel kann einem mit Mdadm verwalteten Software-RAID 5 jetzt einen weiteren Datenträger an die Seite stellen, der als Writeback-Cache dient (u. a. 1, 2, 3, 4, 5). Beim Einsatz einer SSD als Cache-Datenträger für ein RAID aus Festplatten kann das die Schreib-Performance des RAIDs deutlich steigern, denn Anwendungen sehen die Daten dann bereits als geschrieben an, sobald die SSD sie gespeichert hat. Der Kernel überführt die Daten erst später von der SSD auf die Festplatten des Arrays, die typischerweise langsamer sind. Allein dadurch sorgt die SSD bereits für einen Geschwindigkeitszuwachs; durch den Ansatz sammeln sich aber auch größere Datenmengen zum Schreiben an, sodass ein Stripe des RAID häufiger komplett gefüllt werden kann, was hilft, Read-Modify-Write-Zyklen zu vermeiden.

Das Ganze funktioniert mit dem Code für ein Log-Device, das seit Linux 4.4 im Kernel steckt. Bislang war die Funktion vorwiegend dazu gedacht, die Datenintegrität von RAIDs zu steigern. Die Erweiterung, um ein Log-Device auch als Writeback-Cache nutzen zu können, war aber bereits von Anfang an geplant. Die neue Funktion gilt noch als experimentell und lässt sich daher vorerst nicht ohne weiteres nutzen.

Zwischen den Anpassungen am MD-Code war ferner die FAILFAST-Funktion. Durch sie markiert der Kernel einen Datenträger, der Lese- und Schreibfehler hat, bei einem RAID 1 oder 10 deutlich schneller als kaputt (FAILED) (u. a. 1, 2, 3, 4, 5, 6). Das vermeidet Latenzen, die das System sonst womöglich so weit verlangsamen, dass es einem Totalausfall gleichkommt.

Noch mehr neue und verbesserte Treiber

Linux 4.10 unterstützt rund 450 Geräte oder Geräteklassen mehr als sein Vorgänger. Dieser für neue Versionen der Hauptentwicklungslinie von Linux typische Wert geht aus den Datenbanken der Linux Kernel Driver DataBase (LKDDb) hervor.

Unter der neu unterstützten Hardware ist etwa Support für 25G-Netzwerk-Übertragungen im von Intel entwickelten Treiber i40e. Mit dem neuen Kernel sollen auch die Touchpads neuere Asus-Notebooks funktionieren, deren Touchpads per I2C angebunden sind. Ganz neu dabei ist ein Treiber des für die Playstation 3 gedachten uDraw Tablets. Details zu weiteren Verbesserungen an Treibern liefern die Kommentare der wichtigsten Git-Merges in den Bereichen Driver-Core, EDAC, HID, Hwmon, Input LEDs, Media, Platform (1, 2),  RDMA, Sound, Staging und USB.

Umstrukturierungen und Verbesserungen für Nvidia-GPUs

Unter den Änderungen an Grafiktreibern war eine größere Umstrukturierung beim Treiber Nouveau, die Wartung und Weiterentwicklung erleichtern soll. Durch die Umbauten verwendet der Treiber für Nvidias Grafikprozessoren nun die bei Linux 3.19 integrierte Atomic-Infrastruktur, die einige grundlegende Probleme bei der Bildkoordination und der Monitor-Ansteuerung beseitigt (u.a. 1, 2, 3, 4, 5).

Neu bei Nouveau ist auch Basis-Support für Multi-Stream Transport (MST). Dadurch kann der Treiber nun auch 4K- und andere HiDPI-Displays per DisplayPort ansteuern, die sich beim Betriebssystem wie zwei unabhängig voneinander arbeitende Bildschirme melden. Nouveau unterstützt jetzt auch den Grafikchip GP106, der auf der GeForce 1060 sitzt. Außerdem zog ein Schwung von Änderungen ein, durch die das Hoch- und Runtertakten bei Fermi-, Kepler- und Maxwell-Grafikchips nun besser (und bei manchen Chips erstmals) unterstützt wird, sofern man es denn aktiviert.

Bei Titan-Grafikkarten lässt sich jetzt regeln, wie hell das Nvidia-Logo der Karte das Gehäuseinnere illuminiert. Das ist sicherlich eines der weniger wichtigeren Treiber-Features – aber auch Entwickler von Linux-Treibern müssen halt mal entspannen und arbeiten daher manchmal an Dingen, nach denen ihnen gerade der Sinn steht.

Feinschliff für AMD- und Intel-Treiber

Neben den Grafikprozessoren Polaris 10 und 11, die bei Radeon RX 460 bis 480 zum Einsatz kommen, unterstützt der Amdgpu-Treiber jetzt auch Polaris-12-GPUs (1, 2, 3); ein darauf aufsetzener 3D-Grafiktreiber steckt im Mitte Februar veröffentlichten Mesa 17.0. Produkte mit diesen GPUs hat AMD aber noch nicht angekündigt und es ist noch vollkommen unklar, für welches Marktsegment diese vorgesehen sind. Davon abgesehen gab es viel Feinschliff am von AMD selbst entwickelten Treiber; darunter eine Änderung, durch die sich jetzt die Drehzahl von Grafikkartenlüftern auslesen lässt.

Bei Treiber für Intel-GPUs gab es einige Änderungen, um HDMI beim Core-i-6000er-Prozessor und anderen Skylake-CPUs besser zu unterstützen. Unter einem ganzen Schwung von Detailverbesserungen sind Priority Boosting beim GPU Scheduler und Fehlerkorrekturen für DisplayPort-Audio.

Explizite Synchronisationspunkte zum Bildzusammenbau

Nach einigen Vorarbeiten bei Linux 4.9 bietet der Kernel jetzt eine Infrastruktur, mit der Grafiktreiber  "Explicit Fencing" implementieren können (u.a. 1, 2). Die Technik ermöglicht Desktop-Oberflächen und Programmen, den Aufbau ihrer Bedienoberfläche besser zu koordinieren; ferner müssen auch Vulkan-Treiber diese expliziten Synchronisationspunkte beherrschen, um die 3D-Programmierschnittstelle korrekt zu unterstützten.

Durch Explicit Fencing können Anwendungen letztlich das Zusammensetzen von verschiedenen unabhängig voneinander berechneten Bildpuffern mit Hilfe von Barrieren selbst synchronisieren. Das kann etwa bei der Darstellung eines Video-Players relevant sein, wenn sich der Buffer mit dem dargestellten Fensterinhalt dort aus einem Buffer mit der Bedienoberfläche und einem mit dem Videobild zusammensetzt. Bislang kann die Bedienoberfläche bei unabhängiger Berechnung der beiden Buffer komplett ins Stocken geraten, wenn auf den Buffer mit dem Videobild gewartet werden muss, weil der noch nicht vollständig gefüllt wurde.

Weitere Details zur neuen Technik erläutern drei zusammengehörende Blog-Beiträge eines der Entwickler (1, 2, 3). Einen anderen Blick liefert ein Artikel bei LWN.net; er bezieht sich auf einen Vortrag zum Explicit Fencing, von dem die Videoaufzeichnung und die Präsentationsfolien im Netz stehen.

Noch mehr Grafiktreiber

Der Kernel kann nun ohne weitere Treiber den TV-Ausgang der verschiedenen Raspberry-Pi-Modelle aktivieren, denn der VC4-Treiber weiß jetzt deren Video-Encoder zu nutzen. Der Support für Fragment Shader Threading in VC4 verspricht, die Grafikperformance von Raspis zu steigern.

Der MSM-Treiber unterstützt jetzt auch die Adreno-GPUs der 500er-Serie, die häufig in neueren Qualcomm-Prozessoren stecken.

Das Framebuffer Subsystem (Fbdev), auf dem Grafiktreiber für Embbeded-GPUs bis vor einigen Jahren oft aufbauten, hat niemand mehr, der sich aktiv um Weiterentwicklung und Pflege kümmert: Der bisherige Betreuer hat den Posten aufgegeben, ein Neuer konnte nicht gefunden werden. Das stärkt die Position des DRM (Direct Rendering Manager), auf dem die Kernel-Treiber für AMD-, Intel- und Nvidia-GPUs schon lange aufsetzen; seit wenigen Jahren docken dort auch Grafiktreiber für Embedded-GPUs immer häufiger an.

Das DRM-Subsystem des Kernels bringt jetzt auch einen Treiber für den Display Controller in SoCs (System-on-a-Chip) von ZTE mit. Neu dabei ist auch ein DRM-Treiber für den Amlogic Meson Graphic Controller, die Silicon Image SII8620 HDMI/MHL bridge und die MXSFB Controller der ARM-SoCs i.MX23/28/6SX.

Weitere Details zu diesen und anderen Änderungen an den Grafiktreibern listet der Haupt-Git-Merge-Commit für das DRM-Subsystem.

Support für SMR-Festplatten kommt

Unter den Änderungen am Block-Layer (1, 2) waren ferner Patches, durch die der Kernel jetzt die Zoned Blocks in Festplatten mit Shingled Magnetic Recording (SMR) handzuhaben weißt (u. a. 1, 2). Bei solchen sind die Platten in Zonen unterteilt, bei denen eine neu geschriebene Spur die zuvor geschriebene ein wenig überlappt, wie es bei Dachschindeln (englisch "Shingle") der Fall ist. Dadurch lassen sich auf der Plattenfläche mehr Daten unterbringen; zugleich muss durch diesen Ansatz aber die komplette Zone neu geschrieben werden, um ein zuvor geschriebenes Bit zu ändern.

Ebenfalls neu: Der Kernel bringt nun auch einen Host- und Target-Driver mit, um über Fibre Channel auf NVM-Express-Geräte in anderen Systemen zuzugreifen (u. a. 1, 2, 3, 4)

Mit den Änderungen beim Subsystem für ATA-Geräte stießen Patches zum Kernel, durch die der Kernel jetzt ATA Command Priorities nutzen kann; diese können Latenzen in bestimmten Fällen reduzieren, müssen aber explizit aktiviert werden (u. a. 1, 2).

Beim Network Block Device (NBD) soll Multi-Connection Support für bessere Performance sorgen.

Details zu einigen anderen Änderungen im Storage-Bereich finden sich in den Git-Pull-Kommentaren der Subsysteme Device Mapper, Libnvdimm (1, 2) und SCSI ( 1, 2).

Ext4 robuster, XFS flotter

Unter den Änderungen an Ext4 waren einige, die das Dateisystem deutlich robuster machen sollen, falls Angreifer dem Kernel ein gezielt korrumpiertes Dateisystem unterjubeln.

Beim Btrfs-Dateisystem gab es kleinere Detailverbesserungen. Einige von ihnen sollen seit längerem bekannte Fehler aus der Welt schaffen.

Das XFS-Dateisystem hat unter anderem einen neue Direct-IO-Implementation auf Basis der jüngst eingeführten Iomap-Codes bekommen, die einfacher und schneller arbeiten soll.

Beim OverlayFS gab es Änderungen, durch die das Dateisystem zum Übereinanderschichten mehrerer Dateisysteme nun das Umbenennen von Dateien und Verzeichnissen unterstützt (u. a. 1, 2, 3, 4).

Durch die an an Ubifs vorgenommenen Anpassungen ist das Dateisystem jetzt in der Lage, einzelne Dateien und Verzeichnisse selbst zu verschlüsseln (u. a. 1, 2, 3). Das gelingt mit Hilfe der Fscrypt-Infrastruktur, auf die bereits Ext4 und F2FS für ihre Verschlüsselungsfunktionen zurückgreifen.

Das vornehmlich für sehr simple Flash-Datenträger entwickelte Logfs wurde entfernt, weil immer mehr Probleme aufgetaucht seien, sich aber keiner mehr so richtig um den Dateisystemcode gekümmert habe.

Änderungen in anderen Bereichen rund um die Datenspeicherung listen die Git-Merges der Subsysteme Ceph, F2FS, MTD, MMC, NFS-Client und NFS-Daemon auf.

Crypto-Beschleuniger in VMs nutzen

Über den neuen Treiber virtio-crypto können Virtual Machines (VMs) die Crypto-Beschleuniger des Host-Systems verwenden. Das kann bestimmte Verschlüsselungsverfahren deutlich beschleunigen, erfordert neben dem neuen Kernel-Treiber aber auch Support in Qemu.

Der Kernel kann seinen Zufallszahlengenerator nun in einer frühen Phase des Boot-Vorgangs mit Daten initialisieren, die er aus einer EFI-Variable bezieht. So sollen früh beim Systemstart bessere Zufallsdaten zur Verfügung stehen. Ein Boot-Manager oder ein UEFI-Treiber kann die EFI-Variable mit mit Zufallsdaten füllen, die der Kernel beim Initialisieren des Random Number Generator (RNG) dann als Seed verwendet.

Einige weitere Änderungen rund um Security und Crypto finden sich in den Git-Kommentaren für die Subsysteme Audit, Crypto, Namespaces und Security.

Neue Analysemöglichkeiten

Es gab wieder zahlreichen Änderungen an "perf" und der Kernel-Infrastruktur, die die Werkzeugsammlung zur Performance-Analyse verwendet. Diese Anpassungen haben etwa das Kommando perf c2c gebracht, das Problem bei der Nutzung der Prozessor-Caches finden kann, die sich negativ auf die Performance auswirken (u. a. 1, 2). Ebenfalls neu ist perf sched timehist, das eine bedarfsgerechte Analyse der Scheduler-Aktionen ermöglicht (u. a. 1, 2, 3).

Unter den Änderungen am EFI-Code waren welche, durch die der Kernel jetzt Thunderbolt-Geräte auf Macbooks "voll unterstützen soll", wie es in den Commit-Kommentaren heißt (u. a. 1, 2, 3).

Wie wichtig Detailänderungen sein können, zeigt eine Änderung am PCI-Code. Durch diese hält der Kernel jetzt im Sysfs eine Datei bereit, über sich die die Revision von PCI/PCIe-Geräten abfragen lässt, die der Kernel einmal beim Start abfragt und sich dann merkt. Eine neue, diese Funktion nutzende Libdrm kann damit eine zwei- bis dreisekündige Verzögerung vermeiden. Eine solche tritt derzeit auf manchen Systemen beim Start von Programmen wie Firefox, Thunderbird oder Chromium auf, weil die Libdrm dabei die Revisions-Information braucht; dazu muss die Bibliothek das PCI/PCIe-Gerät bislang direkt ansprechen, was eine Verzögerung nach sich zieht, wenn das PCI/PCIe-Gerät schläft und daher zur Abfrage aus dem Schlafzustand geweckt werden muss.

Der Kernel kann nun auch PCIe-Ports schlafen legen, die laut System hotplug-fähig sind; das kann die Leistungsaufnahme von Systemen reduzieren und so unter anderem die Akkulaufzeit von Notebooks steigern.

Um möglich kleine Kernel-Images bauen zu können, lassen sich Posix Timers nun bei der Kernel-Konfiguration ausschalten. Das Image wird dadurch zirka 25 KByte kleiner. Das kann für schwachbrüstige Hardware relevant sei, wie sie beim Internet of Things (IoT) zum Einsatz kommt.

Über das neuen Kconfig-Keyword "imply" können die Kernel-Entwickler die Abhängigkeiten zwischen verschiedenen Konfigurationsoptionen besser steuern.

Unter den Änderungen an KVM waren welche, durch die Microsofts Hyper-V jetzt auch in Virtual Machines (VMs) funktioniert, die per Nested Virtualization aus einer anderen VM gestartet wurden, die auf einem Host mit Intel-Prozessor läuft.

Weitere Änderungen rund um die Infrastruktur erläutern die Git-Merges für ACPI, Dokumentation, IOMMU, Locking, PCI, Power Management, Scheduler, Thermal Management, Tracing, VFIO, Virtio/Vhost und Xen.

Den neuen Linux-Kernel herunterladen und einrichten​

Die neue Linux-Version steht wie gewohnt über Kernel.org zum Download bereit. Hinweise zur Einrichtung eines eigenen Kernels finden Sie im Artikel "Linux-Kernel maßgeschneidert". Das darin beschriebene Make-Target make localmodconfig erzeugt weitgehend automatisch eine auf Ihr System zugeschnittene Kernel-Konfiguration, mit der Sie in wenigen Minuten eine neue Linux-Version einrichten können.

Fedora und Rolling-Release-Distributionen wie Arch Linux, Gentoo und OpenSuse Tumbleweed dürften das neue Linux in den nächsten Wochen über die Systemaktualisierung erhalten. Bei OpenSuse Leap, Ubuntu und vielen anderen klassisch gewarteten Distributionen wird das nicht passieren, denn dort macht der Kernel normalerweise nur beim Wechsel auf eine neue Ausgabe der Distribution einen Versionssprung.

Prozessor effizienter nutzen

Der Kernel unterstützt die "Turbo Boost Max Technology 3.0" neuerer Intel-Prozessoren jetzt besser. Bei diesen kann einer der CPU-Kerne etwas höhere Frequenzen erreichen als die anderen. Der Prozess-Scheduler weiß jetzt um diesen Umstand und delegiert Tasks gezielt an den schnelleren Kern, um so die verfügbare Rechenpower besser auszunutzen.

Der Kernel unterstützt jetzt Intels Cache Allocation Technology (CAT). Mit ihrer Hilfe können Admins den Cache moderner Intel-Prozessoren partitionieren, damit nicht irgendeine nur vorübergehend laufende Anwendung unabsichtlich die Daten einer wichtigeren Anwendung aus dem Cache kickt und diese so erheblich verlangsamt. Details hierzu liefert die zugehörige Dokumentation und der LWN.net-Artikel "Controlling access to the memory cache".

Einige andere Detailverbesserungen an der x86-Unterstützung nennen die Git-Merges zum Assembler-Code, Microcode-Loader und Timern. Darunter etwa eine Änderung, durch die Linux jetzt die x86-Befehle AVX512IFMA und AVX512VBMI kennt.

Die Standard-Konfigurationsdatei für ARM64-Systeme eignet sich jetzt auch für den Raspberry Pi 3. Neu dabei ist auch Support für den SoC des Nexus 5x. Das sind nur zwei von über tausend Änderungen, die es am Code für ARM (Core, Defconfig, Driver, DT, SoCs) und ARM64 (Core, DT, SoCs) gab.

Details zu den anderen Architekturen liefern Git-Merge-Kommentare in den Subsystemen Powerpc, Remoteproc und S390 (1, 2). Beim Code für die zahlreichen anderen vom Kernel unterstützten Prozessor-Architekturen gab es vorwiegend Detailänderungen.

Ausblick

Mit der Freigabe von Linux 4.10 beginnt jetzt die zweiwöchige Phase, in der Linus Torvalds das Gros der Änderungen für den Nachfolger aufnimmt. Dieses "Merge Window" schließt der Linux-Erfinder typischerweise nach zwei Wochen mit der Veröffentlichung einer ersten Vorabversion. Die läutet zugleich die meist sieben oder acht Wochen lange Stabilisierungsphase ein. Daher dürfte Linux 4.11 am 24. April oder 1. Mai erscheinen, sofern Torvalds und seine Mitstreiter im gewohnten Tempo arbeiten.

Daten und Zahlen zu den jüngsten Versionen des Linux-Kernels

Kernel- Version	Anzahl Dateien¹	Zeilen Quelltext (Ohne Doku)²	Entwick- lungs- zeitraum	Anzahl Commits³	Diffstat⁴
Linux 4.3	51570	20.621.444 (19.031.051)	63 Tage	13.282	10.385 files changed,  642.760 insertions(+),  333.026 deletions(-)
Linux 4.4	52221	20.862.229 (19.243.827)	70 Tage	14.082	10.604 files changed,  713.754 insertions(+),  470.774 deletions(-)
Linux 4.5	52916	21.154.659 (19.489.725)	63 Tage	13.173	11.590 files changed,  1.146.355 insertions(+),  854.286 deletions(-)
Linux 4.6	53660	21.422.808 (19.724.413)	63 Tage	14.618	10.250 files changed,  606.023 insertions(+),  337.875 deletions(-)
Linux 4.7	54400	21.720.955 (19.971.725)	70 Tage	13.433	9909 files changed,  575.816 insertions(+),  277.305 deletions(-)
Linux 4.8	55503	22.071.048 (20.266.168)	70 Tage	14.552	11.483 files changed,  662.558 insertions(+),  314.177 deletions(-)
Linux 4.9	56223	22.348.356 (20.520.460)	70 Tage	17.392	11.416 files changed,  713.497 insertions(+),  436.209 deletions(-)
Linux 4.10	57202	22.839.659 (20.864.595)	70 Tage	14.249	11.913 files changed,  806.420 insertions(+),  312.218 deletions(-)
¹ git ls-tree -r --name-only HEAD | wc -l ² find . -type f -not -regex '\./\.git/.*' | xargs cat | wc -l; echo "($(find . -name *.[hcS] -not -regex '\./\.git/.*' | xargs cat | wc -l))" ³ git-log --pretty=oneline vx.(y-1)..vx.(y) | wc -l ⁴ git diff --shortstat vx.(y-1)..vx.(y)

Versionshistorie dieses Artikels​

Dieser Artikel wurde zwischen Freigabe der ersten Vorabversion und der Fertigstellung von Linux 4.10 mehrfach erweitert, um schrittweise alle wichtigen Änderungen der neuen Kernel-Version zu erläutern. Einmal publizierte Absätze werden dabei nur mehr verändert, wenn triftige Gründe es erfordern.

• 2017-03-01, 13:00 – v2.0.1: Korrektur: Writeback-Cache im MD-Subsystem funktioniert bislang nur mit RAID 5, nicht mit RAID 4 & 6
• 2017-02-20, 06:30 – v2.0: Anlässlich der Freigabe von Linux 4.10 umsortiert, damit Abschnitte zu wichtigeren Neuerungen am Anfang stehen.
• 2017-02-16, 09:30 – v1.2.2: Detailänderungen an verschiedenen Stellen.
• 2017-02-13, 16:15 – v1.2.1: Einstieg angepasst, um RC8 und erwarteten Erscheinungstermin zu erwähnen.
• 2017-02-10, 07:30 – v1.2: Neuerungen bei Storage-Support, Dateisystemen, Infrastruktur und Architektur-Support beschrieben.
• 2017-01-31, 07:00 – v1.1: Änderungen bei Netzwerk-Techniken beschrieben. Link zum dritten Blog-Eintrag zu Explicit Fencing eingebaut.
• 2017-01-25, 09:50 – v1.0.2: Link zu einem weiteren Blog-Eintrag von Gerd Hoffmann eingebaut.
• 2017-01-17, 08:15 – v1.0.1: Link zum Blog-Eintrag von Gerd Hoffmann integriert, der sich mit dem Entwicklungsstand von GVT/KVMGT beschäftigt.
• 2017-01-17, 07:00 – v1.0: Erste Version, die sich auf die Neuerungen bei Grafiktreibern konzentriert.

(thl)