Kernel-Log – Was 2.6.39 bringt (3): Architektur und Infrastruktur | heise online
heise PlusAbo
Anzeige

Kernel-Log – Was 2.6.39 bringt (3): Architektur und Infrastruktur

Mit 2.6.39 verschwindet das Big Kernel Lock (BKL) ganz. Interrupts kann der Kernel nun mit Threads abarbeiten, was Latenzen reduziert. Zum Xen-Code stieß das für den Dom0-Betrieb benötigte Netzwerk-Backend – es sieht aber nicht danach aus, als würde das Storage-Backend bald folgen.

vorlesen Druckansicht 1 Kommentar lesen
Lesezeit: 38 Min.
c't Magazin
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

In der Nacht von Dienstag auf Mittwoch hat Linus Torvalds die sechste Vorabversion des Linux-Kernels 2.6.39 freigegeben. Sie enthält verschiedene, vorwiegend kleine Änderungen. Laut Torvalds spüren die Kernel-Entwickler aber noch einigen Problemen nach, daher werde das nicht der letzte RC sein. Es dürfte daher wohl noch mehr als zehn Tage dauern, bis 2.6.39 erscheint.

Das Kernel-Log nimmt die fortschreitende Entwicklung von 2.6.39 zum Anlass, die Mini-Serie "Was 2.6.39 bringt" mit der Beschreibung der Neuerungen rund um Architektur- und Infrastruktur-Code des Kernels fortzusetzen. Der erste Teil der Artikel-Reihe hat sich den Änderungen an Netzwerk-Treibern und -Infrastruktur gewidmet, der zweite Storage- und Dateisystem-Code; in der kommenden Woche wird noch ein Artikel zu Treibern folgen.

Nachdem die Kernel-Hacker bereits in den letzten Monaten allen auf gängigen Systemen genutzten Bereichen des Kernels die Nutzung des Big Kernel Lock (BKL) ausgetrieben hatten, verschwindet dieser Sperrmechanismus nun ganz; in dem dafür zuständigen und mit "BKL: That's all, folks" betitelten Commit bedankt sich Arnd Bergmann bei den wichtigsten Kernel-Entwicklern, die dies Vorhaben zusammen mit ihm vorangetrieben haben. Teilweise wurde der das BKL nutzende Code modifiziert, sodass er nun ohne den Sperrmechanismus auskommt (u. a. 1, 2, 3, 4, 5, 6); es flogen aber auch einige noch auf das BKL angewiesen Treiber und Funktionen raus, die nicht mehr eingesetzt werden oder durch anderen Code beerbt wurden (u. a. 1, 2, 3)

Eine Korrektur am Scheduler beseitigt ein Problem, durch das mit KVM aufgesetzte Windows-Gastsysteme extrem lange zum Booten brauchen, wenn dem Gastsystem viele Prozessoren zugeteilt werden (Änderung, Git-Pull-Request, LWN.net-Artikel mit Hintergründen). KVM beherrscht nun zudem die asynchrone Abarbeitung von Page Faults – das Gast-System kann so vorübergehend einen anderen Thread ausführen, während der Host gerade eine Speicherseite aus dem Auslagerungsspeicher zurückholt, die der aktuelle Thread angefordert hat. Das hatte ursprünglich schon Bestandteil von 2.6.38 werden sollen, musste dann aber zurück stehen, weil Torvalds und andere Entwickler mit einigen Details nicht zufrieden waren. Hintergründe und Benchmark-Ergebnisse zu der Technik liefert eine frühere Patch-Serie und eine Präsentation von Gleb Natapov, der die Änderungen vorangetrieben hat.

Zum Xen-Code stieß Unterstützung für Xenbus PM Events, die Gastsysteme über Powermanagement-Events informieren – etwa Suspend oder Hibernate. Nach der bei 2.6.37 integrierten Basis-Infrastruktur zum Betrieb als Xen-Host (Dom0) folgte mit Kernel 2.6.39 das Netzwerk-Backend, über das die Frontend-Treiber in Xen-Gästen (DomU) mit anderen Systemen kommunizieren. Das Storage-Backend fehlt allerdings weiterhin, daher wird auch mit dem 39er-Kernel kein sinnvoller Betrieb als Dom0 möglich sein, ohne weitere Patches einzubinden. Möglicherweise wird sich daran auch so bald nichts ändern: Als die Xen-Entwickler vor einigen Wochen das Storage-Backend zur Begutachtung an die LKML gesendet haben, hat ein einer der langjährigen Kernel-Hacker die Änderungen deutlich kritisiert und abermals angeregt, einen ganz anderen Ansatz zu nutzen.

Interrupts, Staccato

Die "Forced Threaded Interrupt Handlers" verlagern die Verarbeitung fast aller Interrupts in Kernel-Threads, wenn man den Kernel mit dem Parameter "threadirqs" startet. Damit kommt eine der letzten wichtigen Funktionen im Hauptentwicklungszweig von Linux an, die der Realtime-Zweig nutzt, um Linux Echtzeit-Fähigkeiten zu verleihen; dort wird die Technik standardmäßig genutzt, um lange Latenzen bei der Abarbeitung von Interrupts zu vermeiden.

Vorangetrieben wurde die Änderung vom deutschen Kernel-Entwickler Thomas Gleixner. Der Chef von Linutronix hat in dem Zug zahlreiche Aufräumarbeiten am Code zur Interrupt-Behandlung vorgenommen und verschiedene Implementierungen im Architektur-spezifischen Code zusammengeführt, um Probleme oder Unsauberkeiten aus der Welt zu schaffen – dabei zeigte er Einfallsreichtum und nannte eine private Variable core_internal_state__do_not_mess_with_it, damit andere Entwickler nicht wieder auf die Idee kommen, Interna des generischen IRQ-Codes hinterrücks zu modifizieren.

In einem Vortrag hat Gleixner kürzlich einen Überblick über die Bestrebungen gegeben, weitere Verbesserungen des Echtzeit-Kernels in den Hauptentwicklungszweig zu überführen. LWN.net hat die wichtigsten Punkte in einem Artikel zusammengefasst; demnach kamen im Vortrag auch einige Änderungen am kleine Speicherhäppchen austeilenden SLUB-Memory-Allocator zur Sprache, durch die der Code ab dem 39er-Kernel nun "Lockless" arbeitet und teilweise bis zu 40 Prozent flotter sein soll. Das gilt aber nur für den in bestimmten Situationen nicht nutzbaren Fastpath und nicht den Slowpath, wo SLUB laut Commit-Kommentar die größten Performance-Probleme zeige.

  • Ab 2.6.39 lassen sich via /sys/firmware/dmi/ die Daten auslesen, die moderne PCs über das Desktop Management Interface (DMI) bereitstellen – etwa System-Hersteller, Mainboard-Name oder Speicherausstattung (1, 2); zum Abfragen diese Informationen diente bislang meist das auf Root-Rechte angewiesene Programm dmidecode. Neu ist auch /sys/firmware/efi/vars/, über das sich einige (U)EFI-Variablen abfragen lassen.
  • LWN.net-Chef Jonathan Corbet hat die dem Kernel beiliegenden Dokumente erweitert, die den Entwicklungsprozess des Linux-Kernels näher erläutern.
  • Das neue Make-Target "tarxz-pkg" erstellt ein mit XZ komprimiertes Tar-Archiv eines zuvor kompilierten Kernels
  • Der Kernel lernt mit Version 2.6.39 den Umgang mit Unicore32-CPUs und -Systemen (u. a. 1) – einer an der Universität Peking entwickelten 32-Bit-RISC-Architektur, die vornehmlich in China eingesetzt wird.
  • Der 39er-Kernel unterstützt die Funktionen zum Partitionieren des L3-Caches, welche einige der auch als Bulldozer oder "Family 0x15" bezeichnete CPUs enthalten, die AMD diesen Sommer einführen will.
  • Der x86-Code bietet nun eine "minimale" Unterstützung für Device Trees. Im PPC-Port werden diese schon länger genutzt, um dem Kernel beim Booten Informationen zu den Hardware-Ressourcen mitzugeben; bei einigen vornehmlich für den Embedded-Bereich gedachten x86-System sollen Device Trees laut Commit-Kommentar Informationen zu I2C/SPI, IO APIC oder HPET übermitteln.
  • Die Verzeichnisse mit dem Code zur Unterstützung der Architekturen m68k und m68knommu haben die Kernel-Entwickler zusammengelegt, um die Wartung dieser verwandten Architekturen zu erleichtern.
  • Zu den zahlreichen vom ARM-Code unterstützten Prozessoren und Plattformen zählen nun auch die SOCs der 85xx-Serie von VIA/WonderMedia oder das Efika Smartbook. Dutzende Verbesserungen gab es auch am Code für Nvidias Tegra-Prozessoren (siehe "kleine Perlen" am Ende des Artikels); mit ihnen stieß auch Unterstützung für Toshibas ARM AC100 zum Kernel. Ein c't-Artikel hatte sich vor einiger Wochen mit dem Einsatz eines modifizierten Ubuntu 10.10 auf diesem mit Android ausgelieferten ARM-Netbook beschäftigt. Während der Entwicklung von 2.6.39 gab es auf der LKML indes mehrere Diskussionen rund um Probleme bei der Zusammenarbeit zwischen den ARM-Entwicklern und deren Interaktion mit Linus Torvalds; einen Überblick über die Hintergründe liefert LWN.net in den Artikeln "ARM wrestling" und "Rationalizing the ARM tree".
  • Der Kernel bietet nun einige neue, mit "kstrto" beginnende Funktionen, mit denen sich Strings zuverlässiger in Int-Werte umsetzen lassen.
  • Die Kbuild-Infrastruktur bietet nun den Makefile-Schalter "W=1", der GCC den Code strikter prüfen lässt.
  • Der Capabilities-Code bietet jetzt einige Funktionen, damit unprivilegierte Nutzer einen eigenen Namespace anlegen können – etwas um einen Container anzulegen (1, 2, 3). Die jetzt integrierten Patches ermöglichen das allerdings noch nicht, sondern schaffen laut Commit-Kommentar lediglich 90 Prozent der dazu benötigten Infrastuktur. Hintergründe dazu liefert LWN.net in Linux capabilities support for user namespaces.
  • Der Code für die Dynamic-Debugging-Infrastruktur kennt nun weitere Flags, die ihn zur Ausgabe von Eigenschaften wie Modulnamen, Funktion oder Zeilennummer von Debug-Codeaufrufen bewegen. LWN.net nahm das zum Anlass, die Nutzung dieser recht einfach einsetzbaren Debug-Infrastruktur in einem Artikel zu erläutern.
  • Die Kernel-seitige Code für das Perfomance Monitoring mit Perf spricht nun auch Intels Anfang des Jahres eingeführten Sandy-Bridge-Prozessoren an.
  • Neben der Unterstützung für Python in "perf script" bietet das dem Kernel-beiliegenden Performance- und Tracing-Tool Perf nun auch ein Python-Modul, das sich in andere Python-Programme importieren lässt.

Die kleinen Perlen: Infrastruktur

Die kleinen Perlen: Infrastruktur

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 angezeigten Commit-Kommentar und der darunter ausgegebene Patch liefern zahlreiche weitere 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 and Security

MM

PCI

PM

Scheduler

Tracing

Visualisation

Various

Die kleinen Perlen: Architektur-Code

Die kleinen Perlen: Architektur-Code

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)

Beliebte Bestenlisten

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