Kernel-Log – Was 3.0 bringt (3): Architektur, Infrastruktur und Virtualisierung

Sechs Jahre später als ursprünglich erwartet enthält der Kernel nun alles Wichtige zum Betrieb als Xen Dom0. Bei Linux 3.0 gehen die Entwickler einige Probleme im ARM-, Reboot- und UEFI-Code an. Das Optimieren auf kleinen Code per Compiler-Schalter gibt Torvalds etwas enttäuscht auf.

In Pocket speichern vorlesen Druckansicht 14 Kommentare lesen
Lesezeit: 32 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

In der Nacht von Montag auf Dienstag hat Linus Torvalds eine weitere Vorabversion von Linux 3.0 veröffentlicht. In der Freigabe-Mail zum RC6 hebt er die Aufnahme des Isci-Treibers (u. a. 1) für den SAS-Controller in Intels Server- und Workstation-Chipsatz C600 hervor, der in den kommenden Monaten erscheinen soll. Da der Treiber vergleichsweise groß ist, war sich Torvalds unsicher, ob er so spät im Entwicklungszyklus noch aufgenommen werden soll. Da der Treiber-Code aber für sich alleine stehe, könne er keine Fehler auslösen, die frühere Kernel nicht gezeigt haben.

Von dem Treiber abgesehen hat es vorwiegend kleine Korrekturen an verschiedenen Stellen gegeben. Torvalds deutete an, dem Punkt näher zu kommen, wo er über eine Freigabe von Linux 3.0 nachdenkt, weil es ziemlich ruhig und die Änderungen nicht sonderlich aufregend seien. Das Kernel-Log will daher seine Berichterstattung über die Neuerungen von Linux 3.0 mit einer Beschreibung der Änderungen rund um Architektur, Infrastruktur und Virtualisierung fortsetzen. In den nächsten Tagen folgt der vierte und letzte Teil der "Was 3.0 bringt"-Mini-Serie, der sich Treibern widmen wird; der erste Teil hatte sich mit Netzwerk-Treibern und -Infrastruktur beschäftigt, der zweite mit Dateisystemen.

Unter den für Linux 3.0 aufgenommenen Änderungen findet sich das Storage-Backend für Xen (u. a. 1, 2, 3). Damit enthält der Kernel nun endlich alle essentielle Komponenten, um als Dom0 mit dem Xen-Hypervisor zusammen Gastsysteme zu hosten. Und nicht nur das: Auch der Entwicklerzweig von Qemu enthält seit Mitte Mai alles nötige, um die Hardware für Xen-Gäste zu emulieren, die mit Hilfe der Virtualisierungsfunktionen moderner Prozessoren laufen (HVM/Hardware-assisted Virtualization).

Hintergründe zu diesen beiden lange vorbereiteten Änderungen finden sich in einigen Blog-Einträgen (1, 2, 3, 4, 5, 6). Bei dem in Kernel und Qemu integrierten Code handelt es sich allerdings um eine erheblich zusammengestrichene und überarbeitete Variante des Codes, den kommerzielle Xen-Produkte wie Citrix XenServer derzeit einsetzen. Der Funktionsumfang ist daher kleiner; es lassen sich beispielsweise keine USB-Geräte an Gäste durchreichen und Suspend-to-RAM funktioniert nicht. Die Xen-Entwickler haben daher noch einige Arbeit vor sich, aber die Aufnahme der Hauptkomponenten jetzt endlich geschafft, nachdem die schon 2005 schon zum Greifen nahe schien.

Die Verzögerung bei Xen hat sicher auch zum Erfolg des von KVM (Kernel-based Virtual Machine) beigetragen (siehe auch: Die Woche: Xen hat KVM vorbeiziehen lassen). Der Kernel-eigene Hypervisor unterstützt mit Linux 3.0 nun VIA-Prozessoren und die virtuelle Time Stamp Counter (TSC) Rate neuerer AMD-Prozessoren. Ferner wollen die Kernel-Hacker die Genauigkeit des Emulators und die Performance verbessert haben, wie aus dem Haupt-Git-Pull-Request von KVM-Betreuer Avi Kivity hervor geht. Ferner soll die "Event Index"-Unterstützung in den häufig mit KVM genutzten Virtualisierungsschnittstellen Virtio und Vhost den Overhead beim Datenaustausch zwischen Gast und Host reduzieren.

Neu ist auch Unterstützung für die Supervisor Mode Execution Protection (SMEP) kommender Intel-Prozessoren. Sie versucht zu verhindern, dass Ring-0-Treiber direkt Usermode-Code anspringen können; einige Hintergründe dazu erläutert Dan Rosenberg in einem Blog-Eintrag.

Der Kernel 3.0 wird erstmals die 64-bittige Tilera-Architektur (TILE-Gx) unterstützen – ein Multi-Core-Design der Prozessorfirma Tilera. Der Code für Power-Prozessoren spricht nun die CPUs der Familie PowerEN (Power Edge of Network) an, die auch unter ihrem Codenamen "Wirespeed Pro" (wsp) bekannt sind; einige weitere Power-Neuerungen finden sich im Haupt-Git-Pull-Request für den PPC-Code. Die SMP- und Highmem-Unterstützung für ARM gilt nicht mehr als experimentell (1, 2).

Am ARM-Code gab es erste Aufräumarbeiten, nachdem Torvalds in den vergangenen Monaten die Code-Qualität und die Arbeitsweise der zuständigen Entwickler ziemlich deutlich kritisiert hatte. Ein Kritikpunk waren Dopplungen – im Code für verschiedene SOCs (System-on-a-chip) mit ARM-Kern fand sich teilweise ganz ähnlicher oder eng verwandter Code (etwa Treiber für Funktionseinheiten, die sich in mehreren SOCs finden), zwischen denen kein oder kaum Austausch erfolgte – dadurch traten an einer Stelle korrigierte Fehler an anderen weiter auf. Einige Hintergründe zu diesen und anderen Schwierigkeiten mit dem ARM-Code sowie den teilweise bereits angegangenen Arbeiten zum Beseitigen dieser Probleme liefern einige LWN.net-Artikel, Blog-Einträge und LKML-Diskussionen (1, 2, 3, 4, 5, 6, 7, 8). Ein Baustein zur Verbesserungen ist die in Linux 3.0 eingezogene Unterstützung für Device Trees bei der ARM-Architektur (u. a. 1, 2), was die Portierung auf neue Plattformen und die Wartung des ARM-Codes vereinfachen soll; weitere Verbesserungen in dieser Richtung soll Linux 3.1 bringen.

Einige Änderungen gab es am Code zum Neustarten von PCs; durch sie löst Linux den Reboot nun ähnlich wie neuere Windows-Versionen aus (u. a. 1). Das soll Neustart-Probleme auf einigen Rechnern beseitigen, darunter einige Apple-Systeme und Thinkpad-Notebooks.

Viel mehr Systeme dürften einige Verbesserungen und Fehlerkorrekturen an der Unterstützung des (Universial) Extensible Firmware Interface (U)EFI betreffen, das bei neueren Mainboards BIOS-Funktionen übernimmt (u. a. 1). UEFI ist für die Windows-Welt wichtig, weil die aktuellen Microsoft-Systeme auf UEFI angewiesen sind, um von Datenträgern mit mehr als 2 Terabyte Speicherplatz zu booten. Zur sauberen Parallelinstallation von Linux muss dieses daher auch UEFI nutzen, was bei aktuellen Distributionen aber mehr schlecht als recht der Fall ist. Das könnte mit den jetzt integrierten Kernel-Änderungen etwas besser werden; es gibt im (U)EFI-Umfeld aber noch mehr Probleme, die gelöst werden wollen. Hintergründe dazu finden sich über zwei Kernel-Logs, von denen eines auch auf die Reboot-Probleme näher eingeht (1, 2).

Die Option CC_OPTIMIZE_FOR_SIZE wird nun nicht mehr standardmäßig eingeschaltet. Sie weist den Compiler an, den Code auf Größe zu Optimieren (-Os) – das kann die Performance in bestimmten Situationen verbessern, weil der Prozessor-Cache für Instruktionen effizienter genutzt wird. Das ganze klappt aber nicht ganz so gut wie ursprünglich erhofft, wie Torvalds im Commit-Kommentar zu der von ihm vorgenommenen Änderung etwas enttäuscht anmerkt.

An einigen Stellen des Kernels haben die Kernel-Hacker das Prefetching entfernt (u. a. 1, 2, 3); also das explizite Anfordern von Daten, kurz bevor diese genutzt werden. Das soll eigentlich die Performance verbessern, weil die Daten so vor der Nutzung in den CPU-Cache wandern. Es stellte sich allerdings heraus, dass manche modernen Prozessoren das in bestimmten Situationen selber so gut beherrschen, dass Prefetching durch den Kernel die Performance verschlechtert. Details hierzu liefert LWN.net im Artikel "The problem with prefetch".

Neu ist Cleancache (u. a. Core, FS, Btrfs, Ext3, Ext4): Bei Speicherknappheit kann der Kernel diesem Cache Speicherseiten übergeben, die verzichtbar sind, weil sich der Inhalt durch Nachladen vom Datenträger wieder beschaffen lässt. Da das allerdings langsam ist, versucht Clearcache die Daten im Speicher zu halten – etwa mit Hilfe des bei 2.6.39 integrierten Zcache, das als Cleancache-Backend fungiert und die Daten komprimiert. Beim Zusammenspiel mit dem Xen-Hypervisor kann Cleancache auch den Xen Transcendent Memory als Backend zum Ablegen von Daten nutzen. Der steht auch anderen Gästen zur Verfügung und kann doppelt gespeicherte Daten zusammenführen – das kann die Performance verbessern, wie eine im Commit-Kommentar verlinkte Präsentation erläutert. Weitere Hintergründe liefern die gute Cleancache-Dokumentation und der schon etwas ältere LWN.net-Artikel "Cleancache and Frontswap"

Zum Memory-Management-Code stießen die lange vorbereiteten Patches, die Peter Zijlstra unter dem Schlagwort "MM preemptibility" entwickelt hat und die die Funktion mmu_gather unterbrechbar machen, was Skalierbarkeit, Performance und Echtzeit-Eigenschaften verbessern kann (u. a. 1, 2, 3, 4, 5).

  • Der unter anderem beim Ein- und Ausschalten von Tracepoints oder Dynamic Debugging involvierte Code für Jump Label wurde umgebaut, um den Overhead durch solche Label zu verringern und diese einfacher nutzen zu können – Details liefert LWN.net im Artikel "Jump label reworked".
  • Verschiedene Anwender können beim Einsatz des Function Tracers (Ftrace) nun jeweils unterschiedliche Funktionen filtern.
  • Der Perf-Probe-Code zum Suchen nach Funktionsnamen bietet nun einen Fastpath; der kann diese Aufgabe erheblich beschleunigen, wie Messergebnisse im Commit-Kommentar zeigen.
  • Eine schon in einige Stable-Kernel eingezogene Änderung am Cpufreq-Code beseitigt einen Fehler, der auf manchen Systemen zu einer leicht höheren Leistungsaufnahme geführt hat.
  • Der Intel-IOMMU-Treiber unterstützt jetzt auch Super Pages mit Größen wie 2 MiB oder 1 GiB.
  • Sysfs legt für SELinux jetzt den Pfad /sys/fs/selinux/ an, der langfristig den bisher für SELinux genutzten Mount-Punkt /selinux/ ersetzen soll.
  • Durch einige Änderungen am Capabilites-Framework kann dieses nun Usermode-Helfern bestimmte Funktionen untersagen – etwa damit Anwender über die Capability CAP_NET_ADMIN keine Kernel-Module mehr laden können.
  • Der Kernel bietet nun eine Reihe von mit "kstrtol_" beginnende Funktionen, um von Userland angelieferte Strings in Zahlenwerte zu verwandeln; die neue Funktion "strtobool" verwandelt Zeichenketten aus dem Userland in Boolean-Werte.
  • Über den neuen Kbuild-Parameter "W=" lässt sich vorgeben, welche Art von Compiler-Warnungen beim Übersetzen ausgegeben werden. Es gibt drei Stufen; um alle zu aktivieren, muss man "W=123" angeben, was zu rund 90.000 Warnungen führen soll.
  • Der Kernel bietet nun "Alarm-Timers". Ähnlich wie Hrtimers stoßen sie zu einem bestimmten Zeitpunkt eine Aufgabe an; die Alarm-Timer sorgen aber zusätzlich dafür, dass das System nötigenfalls auch dem Bereitschaftsmodus aufwacht. Aus dem Userspace lassen sie sich über das POSIX-Time-Interface nutzen. Die Android-Entwickler hatten eine ähnliche, Android Alarm Driver genannte Lösung mit einem anderen Userspace-Interface schon vor längerer Zeit entwickelt, damit beispielsweise Smartphones aus dem Suspend aufwachen, um an Termine zu erinnern. Einige Hintergründe zum Konzept liefert der Hauptautor der Alarm-Timers in einem LWN.net-Artikel.
  • TREE_PREEMPT_RCU – eine von mehreren Kernel-Varianten für RCU (Read-copy-update), das den Datenzugriff auf Multi-Processor-Systemen synchronisiert – beherrscht jetzt das für den Echtzeiteinsatz wichtige Priority Boosting. Die Nutzung von RCU wurde weiter ausgebaut – auch die POSIX-Timer nutzen sie, wodurch laut Commit-Kommentar ein Micro-Benchmark erheblich flotter arbeitet. Der RCU-Code wurde zudem an vielen Stellen optimiert (siehe "Die kleinen Perlen"); eine der Änderungen führte zu einer größere Performance-Einbuße in einem Test, welche die Kernel-Hacker aber zum RC4 wieder aus der Welt geschafft haben.
  • Einige Änderungen am Module-Loader (u. a. 1, 2, 3, 4) sollen das Laden von Modulen ein wenig beschleunigen.
  • Die Dokumentation weist darauf hin, dass der Kernel alle Meldungen mit Zeitstempeln versieht, wenn man den Parameter "printk.time=1" übergibt.

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 der Verweise im vorangegangenen Text auf das Webfrontend des von Linus Torvalds gepflegten Git-Zweigs mit den "offiziellen" Kernel-Quellen auf Kernel.org. Der über diese Links angezeigte Commit-Kommentar und der darunter ausgegebene Patch liefern nähere Informationen zur jeweiligen Änderungen.

Vor jedem Link finden sich in eckigen Klammern einige Buchstaben und Zahlen. Ein "C" kennzeichnet Patches mit Änderungen an Kconfig-Dateien, welche die Konfigurationsoptionen samt der zugehörigen Hilfetexte enthalten, 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.

ACPI

Crypto & Security

MM

PCI

Power Management

Scheduler

Tracing

Virtualization

Various

x86

ARM

PPC

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)