Seite 2: Interrupts, Staccato

Inhaltsverzeichnis

Interrupts

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.

Staccato

• 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.