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.
- Thorsten Leemhuis
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.
RIP: BKL
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)
Virtualisierung
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.
