Kernel-Log – Was 3.2 bringt (4): Infrastruktur | heise online
heise PlusAbo
Anzeige

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.

vorlesen Druckansicht 5 Kommentare lesen
Lesezeit: 22 Min.
c't Magazin
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

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.

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.

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.

Storage, Verschiedenes

Bei dem mit Mdadm administrierten MD-Code für Software-RAIDs gab es diesmal keine erwähnenswerten Neuerungen. MD-Maintainer Neil Brown konzentriert sich offenbar auf der Arbeit am Code zum Austauschen von Geräten im Betrieb ("Hot Replace") bei den RAID-Level 4, 5 und 6 sowie den Leveln 1 und 10 – dies sei wohl die Verbesserung, die von den Anwendern am meisten gewünscht wird. Brown hofft, den neuen Code zur Aufnahme für Linux 3.3 einzusenden.

Über das SCSI-Subsystem stieß im Merge Window ein Patch zum Kernel, der Datenträgern zu Alias-Namen verhalf, die sich auch durch einen Neustart nicht veränderten; Hintergründe erläutert ein LWN.net-Artikel. Die Änderungen wurde aber wenige Wochen später wieder entfernt, nachdem sich eine Reihe wichtiger Kernel-Entwickler gegen diesen Ansatz ausgesprochen hatten. Sie waren genau wie mittlerweile auch der der Entwickler der Änderung der Auffassung, dass eine Userspace-Lösung der bessere Ansatz sei; eine solche will der Entwickler der Änderung jetzt vorantreiben.

Userspace-Werkzeuge können mit Hilfe des für Loop-Devices zuständigen Kernel-Code nun eigenständig dafür sorgen, dass Gerätedateien für Partitionen erzeugt werden, wenn das per Loop eingebundene Image eine Partitionstabelle enthält. Der Loop-Code erhielt außerdem Discard-Unterstützung, wodurch sich ungenutzter Speicherplatz in Images freigeben lassen.

Verschiedenes

  • Mit Hilfe des neuen "CFS bandwidth controller" und der Infrastuktur für Control Croups (cgroups) lässt sich die CPU-Zeit von Prozess-Gruppen limitieren, damit beispielsweise Nutzer von Rechenzeit in der Cloud nicht mehr CPU-Ressourcen nutzen können, als sie bezahlt haben (u. a. 1, Dokumentation).
  • Der Kernel markiert sich jetzt mit TAINT_OOT_MODULE (Kurzform für "tainted: out of tree module"), wenn er Module lädt, deren Code nicht Bestandteil des offiziellen Linux-Kernels ist. Dadurch sollen Entwickler, die Fehlerberichte durchsehen, solche Umgebungsbedingungen schnell erkennen. Solche Module haben in Kernel-Kreisen einen schlechten Ruf und lösen gelegentlich Fehler in Bereichen aus, die auf den ersten Blick nichts mit dem Modul zu tun haben. Entstanden ist der Patch nach einer Diskussion, den Kernel beim Laden der Treiber für VirtualBox als "tainted" zu markieren (1, 2)
  • Die Perf-Kommandos Top und Report erhielten eine überarbeitete Oberfläche (u. a. 1).
  • Zusammen mit einem TPM soll das für Linux 3.2 aufgenommene Extended Verification Module (EVM) Manipulationen an Systemdateien aufdecken und so sicherstellen, dass nicht schon beim Systemstart Schadcode geladen wird.
  • Ob es sich bei einem System um einen Desktop-PC, ein Notebook, einen Server oder eine andere von fünf weiteren Geräteklassen handelt, lässt sich jetzt via Sysfs auslesen, sofern diese Angabe korrekt in den ACPI-Tabellen hinterlegt wurde.
  • Über den Verwalter des Codes für Power-Management stieß das im Embedded-Umfeld entstandene DVFS (Dynamic Voltage and Frequency Scaling) zum Kernel. Ähnlich wie Cpufreq reguliert das Devfreq genannte Framework die Frequenz und Spannungsversorgung von Bausteinen des Systems, um idealerweise die Leistungsaufnahme der Chips niedrig zu halten, ohne die Performance allzu negativ zu beeinflussen; Cpufreq erledigt das allerdings für Prozessoren und Devfreq für andere Bausteine. Neu ist auch ein API zum Konfigurieren von Quality of Service bei Geräte-spezifischem Power-Management (Device PM QoS). Hintergründe zu diesen Neuerungen erläutert LWN.net im Artikel "Better device power management for 3.2"
  • Der Code, der den Arbeitsspeicherinhalt beim Ruhezustand (Hibernate/Software Suspend) auf einem nicht nicht-flüchtigen Datenträger sichert, arbeitet jetzt mit Threads. Laut Commit-Kommentar hat das die Lese- und Schreibgeschwindigkeit beim Entwickler und den Faktor zwei verbessert.
  • Durch eine Änderung kann der Kernel nun auch bei PCIe-Geräten regelmäßig abfragen, ob ein Power Management Event (PME) aufgetreten ist. Das ist gelegentlich nötig, um Fehler in der Hardware zu umschiffen. Die Ursachen dafür sind vielfältig und werden im Commit-Kommentar angerissen, der mit den Worten "The land of PCI power management is a land of sorrow and ugliness, especially in the area of signaling events by devices" beginnt und anschließend einige Hardware-Probleme in diesem Bereich erläutert.
  • Der PCI-Code bietet nun Unterstützung für Process Address Space Identifiers (PASIDs). Durch diese auf eine IOMMU (Input/Output Memory Management Unit) angewiesene Technik können PCI-Geräte auf mehrere I/O-Adressbereiche gleichzeitig zugreifen.
  • Das Security-Framework TOMOYO kann nun Umgebungsvariablen prüfen und bestimmte Socket-Operationen unterbinden.
  • Das Krypto-Subsystem bietet ein neues Konfigurations-API, um Krypto-Algorithmen mit Userspace-Programmen zu konfigurieren (u. a. 1); das gelingt etwa mit dem parallel zum neuen Interface entwickelte Crconf.
  • Im Skript-Verzeichnis des Kernel liegt am Version 3.2 ein Skript, um ein mit Bzip2 komprimiertes Kernel-Image zu extrahieren.
  • Dateien im Sysctl-Verzeichnis (/proc/sys/) lassen sich jetzt über die Poll-Funktion auf Änderungen überwachen.
  • Der Init-Code versteht fortan auch Angaben zum einzubindenden Root-Device in der Form "root=PARTUUID=UUID/PARTNROFF=%d", um eine Parition ("PARTNROFF=%d") auf einem bestimmten Datenträger (PARTUUID=UUID) zu spezifizieren.

Die kleinen Perlen

Viele kleinere, aber keineswegs unbedeutende Neuerungen finden sich in der folgenden Liste mit den englischen Commit-Überschriften der jeweiligen Änderung. Die Einträge verlinken genau wie viele Verweise im vorangegangenen Text auf das Webfrontend des von Linus Torvalds gepflegten Git-Zweigs auf Kernel.org, der die gemeinhin als "offiziell" bezeichneten Kernel-Quellen enthält. Der über diese Links angezeigte Commit-Kommentar und der darunter ausgegebene Patch liefern zahlreiche weitere Informationen zur jeweiligen Änderung.

Vor jedem Link finden sich in eckigen Klammern einige Buchstaben und Zahlen. Ein "C" kennzeichnet Patches mit Änderungen an Kconfig-Dateien; diese enthalten die Konfigurationsoptionen samt der zugehörigen Hilfetexte, die bei der Kernel-Konfiguration über "make menuconfig" oder "make xconfig" angezeigt werden. Ein "D" steht bei Patches, die die Dokumentation verändern, die im Kernel-Zweig unterhalb von Documentation/ liegt. Ein "N" weist Änderungen aus, die eine neue Datei anlegen. Die Zahl vermittelt einen groben Eindruck zur Größe des Patches: eine "1" kennzeichnet Änderungen, die inklusive Kommentar zwischen 10 und 20 KByte groß sind, eine "2" für solche, die zwischen 20 und 30 KByte Umfang haben; Änderungen ohne Zahl sind kleiner als 10 KByte, Patches mit einer "9" hingegen 90 KByte oder größer.

BCMA, PCI, PCIe, …

Crypto & Security

Memory Management

Power Management

Scheduler

Storage

Tracing

Various

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich in den vorangegangenen Kernel-Logs auf heise open. Neue Ausgaben des Kernel-Logs werden auf den Identi.ca- und Twitter-Konten "@kernellog" erwähnt; die englischen, bei den Kollegen von "The H" erscheinenden Übersetzungen auf den Identi.ca- und Twitter-Konten "@kernellog2". Gelegentlich zwitschert der Autor des Kernel-Logs unabhängig davon über einige Kernel-Log-Themen bei Identi.ca und Twitter als "@kernellogauthor". (thl) (thl)

Beliebte Bestenlisten

Alle Angebote
Newsletter heise-Bot heise-Bot Push Nachrichten Push Push-Nachrichten