Kernel-Log – Was 3.4 bringt (1): Infrastruktur

Inhaltsverzeichnis

Vergangenes Wochenende hat Linus Torvalds die vierte Vorabversion von Linux 3.4 veröffentlicht; bis zur Freigabe dieser Mitte oder Ende Mai erwarteten Kernel-Version dürften noch zwei bis vier weitere folgen.

Wie üblich haben die Kernel-Entwickler alle größeren Neuerungen dieser Version zu Beginn der Entwicklung aufgenommen. Das Kernel-Log kann daher bereits jetzt einen umfassenden Überblick über die wichtigsten Neuerungen von Linux 3.4 geben, denn es ist sehr selten, dass die Kernel-Entwickler in der jetzt laufenden Stabilisierungsphase noch größere Änderungen integrieren oder Neuerungen wieder entfernen.

Wie gewohnt geben wir eine Übersicht im Rahmen einer Artikelserie, die sich nacheinander verschiedenen Bereichen des Kernels annimmt. Den Anfang macht die folgende Beschreibung der wichtigsten Neuerungen rund um Architektur-Code und grundlegende Infrastruktur; die folgenden Artikel beschäftigen sich mit Grafiktreibern, Dateisystemen, Storage-Unterstützung und Treibern für andere Hardware.

Hybridbetrieb

Für x86-64/x64-Prozessoren übersetzte Kernel können Programmen ab Linux 3.4 ein x32 genanntes ABI (Application Binary Interface) bieten (u. a. 1). Dafür kompilierte Programme haben Zugriff auf die die 64-Bit-Register und -Datenpfade der 64-Bit-Prozessoren, arbeiten aber nur mit 32-Bit-Pointern – die reichen für viele typische Aufgabenstellungen aus und belegen weniger Arbeitsspeicher als 64-Bit-Pointer.

Grob gesprochen vermeiden für das x32-ABI kompilierte Programme so den Overhead, den ein voller 64-Bit-Betrieb mit sich bringt, nutzen aber dennoch einige der wichtigsten Vorteile von 64-Bit-x86-Prozessoren. Letzteres gelingt nicht, wenn man 32-Bit-x86-Programme (x86-32/ix86) auf x86-64-Distributionen ausführt, wie es Linux seit den ersten Tagen der 64-Bit-x86-Unterstützung beherrscht.

Vorangetrieben wurde das Ganze maßgeblich von Intel-Entwicklern. Das neue ABI ist offenbar vornehmlich für den Embedded- und Mobil-Markt gedacht: Mittelfristig dürften Smartphones, Tablets und Co. mit x86-Prozessoren häufiger 4 GByte Arbeitsspeicher oder mehr haben, den ein 32-Bit-Kernel nur mit Tricks ansprechen kann; die meisten Programme auf solchen Geräten dürften aber keine 4 GByte Speicher und damit keine 64-Bit-Pointer benötigen, sodass sich der höhere Speicherverbrauch eines vollwertigen 64-Bit-Betriebs nicht lohnt. Die in diesem Umfeld eingesetzten Prozessoren sind zudem eher schwächer, daher fallen die durch 32- statt 64-Bit-Pointer erzielbaren Vorteile stärker ins Gewicht. Bei typischen x86-Prozessoren für Notebooks, Desktops oder Server ist der Overhead eines vollwertigen 64-Bit-Betriebs eher gering, daher dürften die klassischen x86-64-Distributionen die beiliegende Software weiterhin als 64-Bit-Programme für das native x86-64-ABI mitliefern.

Weitere Hintergründe liefern die Homepage des x32-Projekts und ein LWN.net-Artikel zum neuen ABI.

Virtualisierung

Unter den Änderungen am Xen-Code für Linux 3.4 (u. a. 1, 2) ist eine, durch die der Kernel der Dom0 einige der vom BIOS gelieferten ACPI-Informationen zu den Takt- und Schlafzuständen des Prozessors an den Xen-Hypervisor senden kann, nachdem der Kernel diese interpretiert hat. Der Hypervisor kann sich mit diesen Informationen um das Anpassen des Prozessortakts kümmern (P-States) oder die CPU in Kurzzeitschlafzustände (C-States) versetzen. Das reduziert die Leistungsaufnahme, was die Akku-Laufzeit von Notebooks signifikant verlängern kann.

Durch die Kernel-Interpretation kommt der Xen-Hypervisor weiter ohne vollwertigen ACPI-Interpreter aus. Der Dom0-Kernel kann sich nicht selbst um die Taktanpassung oder das Schlafenlegen kümmern, da der Hypervisor die Kontrolle über das System hat und nur er einen Überblick über die Gesamtauslastung des Systems besitzt; eine laufende Abstimmung zwischen Dom0-Kernel und Hypervisor dürfte zu viel Zeit kosten. Xen erfordert einige solcher Tricks – bei KVM sind die unnötig, weil der zuerst gestartete Linux-Kernel selbst als Hypervisor arbeitet.

KVM kann mit 3.4 nun auch PCI-2.3-Geräte an Gäste weiterreichen, die sich auf dem Host eine Interrupt-Leitung mit anderen PCI-Geräten teilen. Zum SCSI-Subsystem stieß der Treiber Virtio-Scsi, der sich zusammen mit der gleichnamigen Unterstützung in Qemu zu einer Datenträgeremulation eignet, die mit recht wenig Overhead den Datenverkehr zwischen Host und Gast regelt. Der Treiber soll laut seinem Entwickler flexibler sein, besser skalieren und einfacher in der Handhabung sein als Virtio-Blk, das Ähnliches biete, dem aber Funktionen für bestimmte Einsatzgebiete fehlen würden.