Die Neuerungen von Linux 2.6.35
Seite 3: Powermanagement, RAM-Defragmentierung
ACPI, PCI und Power-Management
Der Cpuidle-Code führt nun Buch über die letzten Schlafphasen des Prozessors und versucht wiederkehrende Muster zu erkennen – etwa ein häufiges Aufwachen, kurz nachdem der Prozesser schlafen gelegt wurde. Diese Informationen nutzt der Code, um besser entscheiden zu können, ob und wie tief er den Prozessor in der nächsten Ruhephase schlafen legt. Ferner wertet der Ondemand-Governor des Cpufreq-Codes nun die Wartezeit auf die Fertigstellung von I/O-Aufgaben bei manchen Prozessoren wie normale CPU-Last, sofern man es nicht anders konfiguriert. Diese beiden Änderungen sollen den Datendurchsatz von manchen teilausgelasteten Systemen deutlich steigern, denn in der Vergangenheit hatte der Kernel bei manchen Systemen und Zugriffsmustern die CPU-Stromsparmodi zu aggressiv genutzt, sodass Einschlaf- und Aufwachzeiten der CPU den Datenfluss erheblich verlangsamten.
Dem Kernel liegt nun der experimenteller Treiber intel_idle bei, der direkt einige Stromsparmechanismen von Intel-CPUs kontrolliert, statt dies den häufig schlecht programmierten ACPI-BIOSen zu überlassen – Hintergründe dazu liefert neben dem Commit-Kommentar auch eine Meldung bei LWN.net. Kernel 2.6.35 wird zudem Unterstützung für das in der ACPI-4.0-Spezifikation beschriebene APEI (ACPI Platform Error Interface) inklusive der Error Record Serialization Table (ERST) bieten (u. a. 1, 2, 3, 4, 5, 6, Dokumentation). Über diese Schnittstellen kann die Hardware das Betriebssystem über Hardware-Probleme – etwa beim Chipsatz oder beim Speicher – informieren.
Informationsquelle Quellcodeverwaltung
Viele der Links im Artikel verweisen auf den für die Neuerung jeweils relevanten Commit im Web-Frontend des von Linus Torvalds mit Git verwalteten Linux-Quellcodezweigs auf kernel.org. Dort finden sich viele weitere Informationen zur jeweiligen Änderungen – speziell der Commit-Kommentar im oberen Bereich der vom Git-Web-Frontend angezeigten Webseite ist häufig eine überaus ergiebige Quelle für weitere Informationen, denn dort erklärt der Autor des Patches normalerweise die Hintergründe der Änderungen und deren (erhoffte) Auswirkung. Gelegentlich finden sich dort auch Benchmark-Ergebnisse oder Verweise auf weitere Informationsquellen.
Auf den Commit-Kommentar folgt eine Auflistung der durch den Patch veränderten Dateien. Über den hinter dem Dateinamen zu findenden Link "patch" kann man sich anzeigen lassen, wie der Commit die jeweilige Datei verändert; "history" zeigt frühere Änderungen der Datei an. Weiter unten finden sich alle im Rahmen des Commits durchgeführten Änderungen im Unified-Diff-Format. Dabei handelt es sich größtenteils um Modifikationen am Quellcode des Linux-Kernels – es sind aber nicht selten auch Anpassungen an der Dokumentation oder an Kommentaren im Code darunter, daher finden dort auch Anwender ohne Programmierkenntnisse viele hilfreiche Informationen.
Architektur-Code und Speichersubsystem
Durch Memory Compaction (u. a. 1, 2, 3, 4) kann der Kernel bei Bedarf den Arbeitsspeicher defragmentieren, um große, zusammenhängende Bereiche freien Speichers zu schaffen. Solche lassen sich bei modernen CPUs mit großen Speicherseiten (etwa 2 MByte statt 4 KByte großer Pages) nutzen, was den Verwaltungs-Overhead im Prozessor reduziert und so die Performance gerade bei Virtualisierung oder beim Einsatz großer Datenbanken steigern kann. Weitere Hintergründe zur Speicher-Defragmentierfunktion liefert ein Artikel bei LWN.net.
Linux 2.6.35 bringt zudem volle Unterstützung für die Turbo Core genannte Funktion, durch die einige vor einigen Wochen eingeführte Sechskernprozessoren von AMD den Takt einzelner Kerne steigern, wenn mindestens drei Kerne schlafen. Über Procfs kann man das Vorhandensein von Turbo-Core-CPUs erkennen; via Sysfs lässt sich die Taktsteigerung auf Wunsch deaktivieren. Damit geht die Geschichte um die Performance-Probleme der Turbo-Core-Prozessoren bald zu Ende, nachdem bereits die Stable-Kernel 2.6.32.13, 2.6.33.4 und 2.6.34 Korrekturen brachten, durch die AMDs Sechskerner wenigstens den Nominaltakt erreichten.
