Kernel-Log – Was 3.13 bringt (3): Infrastruktur

Linux 3.13 entlockt Multiprozessor-Systemen mehr Leistung. Es lassen sich jetzt Kernel kompilieren, die bis zu 8192 CPU-Kerne unterstützen.

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

Die Kernel-Entwickler haben die bei 3.8 eingeführten und bislang nur rudimentären Automatiken, um Prozesse und die von ihnen verwendeten Arbeitsspeicherbereiche zusammenzuhalten, erheblich ausgebaut (u. a. 1, 2). Das ist für die im Server-Umfeld häufig anzutreffenden Multiprozessor-Systeme mit NUMA (Non-Uniform Memory Access) wichtig, denn auf lokal angebundenen Arbeitsspeicher greift ein Prozess schneller zu als auf die RAM-Module, die andere Prozessoren betreuen.

Prozesse mit ihren Speicherbereichen zusammenzuhalten steigert die Performance einiger Anwendungen erheblich, daher konfigurieren manche Server-Admins die Zuordnungen manuell; trotz der verbesserten Automatiken dürfte das in manchen Konstellationen aber auch weiterhin Vorteile bieten.

Über neue Sysfs-Dateien kann man das Verhalten der jetzt eingeführten Automatiken beeinflussen. Details zu den Verbesserungen, die Scheduler und Memory-Management-Code betreffen, liefert ein LWN.net-Artikel.

Durch Änderungen am Memory-Management-Code soll Linux 3.13 etwas schneller auf Systemen arbeiten, die verstärkt große Speicherseiten (Huge Pages) nutzen (u. a. 1, 2). Auch einige Verbesserungen am SLAB Allocator versprechen einen kleinen Performance-Gewinn.

Der Kernel kann jetzt versuchen, die von ihm selbst verwendeten Arbeitsspeichersegmente in einem Bereich zu bündeln (u. a. 1, 2, 3). Da sich vom Kernel selbst verwendeter Speicher nach der Allokation nicht mehr verlagern lässt, kann diese Herangehensweise die Speicherregionen vergrößern, die man im Betrieb entfernen kann (Memory Hotplug).

Dem Kernel 3.13 liegt ein Treiber für die Funktion Running Average Power Limit (RAPL) bei, über die sich die Leistungsaufnahme neuerer Intel-Prozessoren begrenzen lässt. Die Konfiguration erfolgt über das parallel eingeführte Power Capping Framework (u. a. 1, 2, 3, 4).

Zum Kernel gehört jetzt auch das Programm tmon. Es interagiert mit der Thermal-Infrastruktur des Kernels, um Daten von Wärmensensoren abzufragen, für die Wärmeentwicklung wichtige Geräte-Beziehungen festzustellen oder für die Wärmeentwicklung wichtige Parameter zu konfigurieren.

Eine ganze Reihe weiterer Verbesserungen rund um Power Management listet der Haupt-Merge dieses Subsystems.

Das neue KVM-VFIO-Device verbessert die Interaktion zwischen dem Hypervisor KVM und VFIO (Virtual Function I/O), das PCI/PCIe-Geräte an Gäste durchreicht. Diese Änderungen macht Funktionen möglich, die zum Durchreichen der Grafikkarte an Gäste wichtig sind. KVM-Virtualiserung gelingt nun auch mit ARMs Cortex-A7.

Es lassen sich nun Kernel kompilieren, die bis zu 8192 CPU-Kerne unterstützen. Bislang waren es halb so viele – laut Commit-Kommentar zu wenig für einige SGI-Systeme, die sich nicht zuletzt auch durch Hyperthreading der Zahl von 6096 Kernen nähern.

Linux versteht jetzt den Boot-Parameter "earlyprintk=efi". Ähnlich wie bei "earlyprintk=vga" versucht der Kernel dann die EFI-Framebufferkonsole früher als gewohnt zu aktivieren; so gelangt man manchmal an Meldungen zu Kernel-Fehlern, die vor dem Punkt auftreten, an dem der Kernel normalerweise die Grafikausgabe aktiviert. Über das neue Extended Error Log lassen sich Hardware-Fehlermeldungen abrufen, die manchmal detailliertere Informationen liefern als andere Interfaces. Neu ist auch Unterstützung für CPER (UEFI Common Platform Error Record) (u. a. 1, 2), eine RAS-Funktion (Reliability, Availability and Serviceability) einiger neuerer Xeon-Systeme.

Der ARM-Code unterstützt jetzt UEFI, Nvidias SoC Tegra 4 sowie die Renesas Shmobile-Platformen Genmai und Koelsch. Die Unterstützung für ARM-SoCs mit Big-Little verbessert der neue In Kernel Switcher (IKS) (u. a. 1, 2). Bei ihm bilden je ein schneller, aber stromhungriger, und ein langsamer, aber sparsamer ARM-Kern einen Verbund, bei der je nach Systemlast der eine oder andere Kern arbeitet. Eine viel flexiblere Ansteuerung und größeres Stromsparpotenzial verspricht Heterogeneous Multi-Processing (HMP), bei dem der Kernel die Kerne nicht paarweise, sondern alle seperat anspricht; der dafür benötigte Kernel-Code hat aber noch einiges an Entwicklungsarbeit vor sich.

Der Kernel kann die normalerweise mit Little Endian laufenden ARM- und ARM64-Prozessoren jetzt auch mit Big Endian betreiben (u. a. 1, 2). Rein zufällig haben die Entwickler des PPC-Code genau bei derselben Kernel-Version das umgedrehte implementiert, denn die normalerweise mit Big Endian arbeitenden PowerPC-Prozessoren kann Linux jetzt auch mit Little Endian betreiben (u. a. 1, 2, 3). Damit das funktioniert, müssen bei beiden Architekturen sowohl Prozessor als auch Plattform den Betrieb mit dem anderen Byte-Encoding beherrschen; x86-Systeme arbeiten immer mit Little Endian.

Über neue Treiber kann der Kernel Rechenaufgaben an PCIe-Steckkarten mit dem 2012 eingeführten Xeon Phi übergeben (u. a. 1, 2, 3, 4, 5). Die Unterstützung für die Architektur Renesas H8/300 (H8300) haben die Kernel-Entwickler indes entfernt. Einige Linux-Entwickler kümmern sich aber durchaus auch noch um ganz alte Hardware: Aaro Koskinen hat Unterstützung zum Hoch- und Runterschalten des Prozessortakts beim iMac G5 (iSight) eingebracht, den Apple vor acht Jahren eingeführt hat (1, 2).

Beim Random-Subsystem gab es zahlreiche Änderungen, die Zuverlässigkeit, Geschwindigkeit und Qualität der vom Kernel gelieferten Zufallsdaten steigern sollen (u. a. 1, 2, 3). Mit den Verbesserungen am Security-Subsystem stießen eine Reihe von Patches zum Kernel, durch die der Kernel-Speicher für Crypto-Schlüssel einige neue Funktionen erhält; diese sind unter anderem für NFS und den Einsatz von Kerberos mit dem Key-Storage des Kernels wichtig. Die dabei integrierte Unterstützung für einen Trusted Key erwies sich allerdings als problematisch und wurde vorerst wieder entfernt.

Es gab wieder eine ganze Reihe von Verbesserungen an der Performance-Monitoring-Infrastruktur "perf", darunter Unterstützung für die Uncore-Bereiche von Intels Ivy Bridge-EP und allerlei Performance-Optimierungen. Unter den Änderungen am Function Tracer Ftrace ist eine, um Unterbereiche bei der Analyse mit einem Function Graph auszublenden.