Kernel-Log – Was 3.2 bringt (4): Infrastruktur
Einige Änderungen am Speichersubsystem sollen Reaktionsgeschwindigkeit und Performance verbessern. Der Device-Mapper beherrscht ab Linux 3.2 Thin Provisioning – und nutzt das für eine verbessere Snapshot-Funktion.
- Thorsten Leemhuis
Zu Beginn des vergangenen Wochenendes hat Linus Torvalds die fünfte Vorabversion von Linux 3.2 veröffentlicht. In der Freigabe-Mail zeigt er sich etwas enttäuscht, weil es seit dem RC4 mehr Commits gegeben habe als zuvor für den zweiten oder der vierten RC; letztlich bringe der fünfte RC aber keine großen oder gefährlich wirkenden Änderungen.
Zum Freigabetermin des Kernel 3.2 macht er keine Angaben; da allerdings viele Kernel-Entwickler zwischen Weihnachten und Neujahr nur gelegentlich an der Tastatur sitzen, dürfte er die kommende Version erst nach Neujahr freigeben, damit das Merge Window von Linux 3.3 nicht in die Zeit zwischen den Jahren fällt. Das Kernel-Log will dennoch die Mini-Serie "Was 3.2 bringt" noch vor Weihnachten zu Ende bringen; nach der Beschreibung der Neuerungen rund um Netzwerk-Treiber und -Infrastruktur, Dateisysteme sowie Architektur- und Prozessor-Unterstützung widmet sich dieser Artikel daher den Entwicklungen bei der sonstigen Infrastruktur des Kernels. Den Abschluss der Mini-Serie wird ein Artikel zu Treibern bilden.
Memory Management
Der Writeback-Code drosselt jetzt Programme effizienter, die viele Daten zum Schreiben auf Datenträger anliefern (u. a. 1, 2, 3, 4, 5). Das soll sicherstellen, dass das System flott auf Benutzereingaben reagiert und nicht durch ein Ansammeln großer Datenmengen in Zwischenspeichern überlastet wird – etwa wenn man mit dem Programm dd auf einen langsamen Datenträger schreibt. Torvalds merkte in der Freigabe-Mail zum 3.2-rc1 an, diese Änderungen sei zwar nur sehr klein, hätten aber das Potenzial, von allen Anwendern bemerkt zu werden. Es sind allerdings durchaus noch Situationen bekannt, wo das System aus Sicht des Anwenders langsam reagiert, weil das Speichersubsystem beschäftigt ist. Mel Gorman arbeitet an Änderungen (u. a. 1, 2), um ein häufiger auftretendes Problem rund um Transparent Huge Pages (THP) zu beseitigen; Hintergründe liefert ein LWN.net-Artikel.
Das neue Cross Memory Attach kann den Overhead bei der Kommunikation zwischen Prozessen reduzieren. Hintergründe zu der Technik, die entwickelt wurde, um das das Message Passing Interface (MPI) schneller zu machen, liefern LWN.net im Artikel "Fast interprocess messaging" sowie die Beschreibung der Funktionsaufrufe. Änderungen am SLUB-Allocator und am Vmscan-Code sollen die Kernel-Performance in bestimmten Situationen verbessern, wie Messwerte in den Commit-Kommentaren zeigen; das gilt auch für die Mremap-Unterstützung und TLB-Optimierungen im Code für Transparent Huge Pages (THP).
Zur Aufnahme eingereicht war auch das bei LWN.net beschriebene Frontswap, auf das etwa Xen und Zcache zurückgreifen können, um zwischengespeicherte Daten beim Xen Transcendent Memory oder komprimiert im Speicher abzulegen. Eine Reihe von Kernel-Hackern sprach sich allerdings gegen die Aufnahme von Frontswap aus; eine Zusammenfassung der Lage durch den Hauptautor des Frameworks änderte daran nichts. Nach einer etwas nach Aufgabe klingenden Mail will Konrad Rzeszutek Wilk helfen, das Framework fit für eine Aufnahme zu machen.
Virtualisierung
Die Front- und Backend-Treiber zum Datenträgerzugriff beim Virtualisieren mit Xen unterstützen nun Discard, sodass der Host erfahren kann, wenn im Gast Speicherbereiche freigegeben werden (1, 2).
Am Kernel-eigenen Hypervisor KVM gab es einige kleinere Optimierungen und Verbesserungen. Das "Native KVM Tool" war abermals zur Aufnahme eingereicht. Den ersten richtigen Anlauf nahm ein als Alternative zum Native KVM Tool vorgeschlagenes Skript, über das man mit wenigen Handgriffen eine virtuelle Machine mit Qemu starten kann, um beispielsweise auf die Schnelle einen neu gebauten Kernel auszuprobieren. Beide Ansätze wurden in diesem Entwicklungszyklus nicht aufgenommen; vermutlich dürften die Entwickler beider Lösungen es bei Linux 3.3 erneut versuchen.
Device Mapper
Der Device Mapper bietet ab 3.2 eine experimentelle "persistent data library"; verschiedene DM-Targets sollen in Zukunft auf dieses Framework zum Speichern von Device-Mapper-Metadaten zurückgreifen können, wie die zugehörige Dokumentation erläutert. Ein erster Nutzer dieser Infrastruktur ist das Device-Mapper-Target "dm-thin", das Funktionen zum Thin Provisioning von Speicherplatz ermöglicht – mit ihm lässt sich also mehr Speicherplatz exportieren, als tatsächlich vorhanden ist.
Das letztgenannte Target bringt zudem eine verbesserte Snapshot-Funktionen mit, die effizienter mit dem Speicherplatz umgeht; sie soll auch dann ordentliche Performance liefern, wenn etwa zu Backup-Zwecken mehrere Snapshot auf einem Datenträger erzeugt werden. Auch dieser Code gilt als experimentell; Hintergründe erläutern die zugehörige Dokumentation und eine Feature-Seite zu Fedora 17, das die Technik nutzen will. Dazu sind neue Userspace-Werkzeuge nötig.
Ebenfalls neu und als experimentell gekennzeichnet ist das Device-Mapper-Target "dm-bufio", das man als Cache beim Zugriff auf Datenträger zwischenschalten kann. Ferner gibt der Device-Mapper jetzt weiter, ob er Datenträger ohne rotierendes Medium, etwa SSDs, verwaltet; diese Information kann den Boot-Vorgang beschleunigen.
