Seite 2: Größenoptimierung, MM, Problemfelder

Inhaltsverzeichnis

Problemfelder

Am ARM-Code gab es erste Aufräumarbeiten, nachdem Torvalds in den vergangenen Monaten die Code-Qualität und die Arbeitsweise der zuständigen Entwickler ziemlich deutlich kritisiert hatte. Ein Kritikpunk waren Dopplungen – im Code für verschiedene SOCs (System-on-a-chip) mit ARM-Kern fand sich teilweise ganz ähnlicher oder eng verwandter Code (etwa Treiber für Funktionseinheiten, die sich in mehreren SOCs finden), zwischen denen kein oder kaum Austausch erfolgte – dadurch traten an einer Stelle korrigierte Fehler an anderen weiter auf. Einige Hintergründe zu diesen und anderen Schwierigkeiten mit dem ARM-Code sowie den teilweise bereits angegangenen Arbeiten zum Beseitigen dieser Probleme liefern einige LWN.net-Artikel, Blog-Einträge und LKML-Diskussionen (1, 2, 3, 4, 5, 6, 7, 8). Ein Baustein zur Verbesserungen ist die in Linux 3.0 eingezogene Unterstützung für Device Trees bei der ARM-Architektur (u. a. 1, 2), was die Portierung auf neue Plattformen und die Wartung des ARM-Codes vereinfachen soll; weitere Verbesserungen in dieser Richtung soll Linux 3.1 bringen.

Einige Änderungen gab es am Code zum Neustarten von PCs; durch sie löst Linux den Reboot nun ähnlich wie neuere Windows-Versionen aus (u. a. 1). Das soll Neustart-Probleme auf einigen Rechnern beseitigen, darunter einige Apple-Systeme und Thinkpad-Notebooks.

Viel mehr Systeme dürften einige Verbesserungen und Fehlerkorrekturen an der Unterstützung des (Universial) Extensible Firmware Interface (U)EFI betreffen, das bei neueren Mainboards BIOS-Funktionen übernimmt (u. a. 1). UEFI ist für die Windows-Welt wichtig, weil die aktuellen Microsoft-Systeme auf UEFI angewiesen sind, um von Datenträgern mit mehr als 2 Terabyte Speicherplatz zu booten. Zur sauberen Parallelinstallation von Linux muss dieses daher auch UEFI nutzen, was bei aktuellen Distributionen aber mehr schlecht als recht der Fall ist. Das könnte mit den jetzt integrierten Kernel-Änderungen etwas besser werden; es gibt im (U)EFI-Umfeld aber noch mehr Probleme, die gelöst werden wollen. Hintergründe dazu finden sich über zwei Kernel-Logs, von denen eines auch auf die Reboot-Probleme näher eingeht (1, 2).

Optimierungen

Die Option CC_OPTIMIZE_FOR_SIZE wird nun nicht mehr standardmäßig eingeschaltet. Sie weist den Compiler an, den Code auf Größe zu Optimieren (-Os) – das kann die Performance in bestimmten Situationen verbessern, weil der Prozessor-Cache für Instruktionen effizienter genutzt wird. Das ganze klappt aber nicht ganz so gut wie ursprünglich erhofft, wie Torvalds im Commit-Kommentar zu der von ihm vorgenommenen Änderung etwas enttäuscht anmerkt.

An einigen Stellen des Kernels haben die Kernel-Hacker das Prefetching entfernt (u. a. 1, 2, 3); also das explizite Anfordern von Daten, kurz bevor diese genutzt werden. Das soll eigentlich die Performance verbessern, weil die Daten so vor der Nutzung in den CPU-Cache wandern. Es stellte sich allerdings heraus, dass manche modernen Prozessoren das in bestimmten Situationen selber so gut beherrschen, dass Prefetching durch den Kernel die Performance verschlechtert. Details hierzu liefert LWN.net im Artikel "The problem with prefetch".

Memory Management

Neu ist Cleancache (u. a. Core, FS, Btrfs, Ext3, Ext4): Bei Speicherknappheit kann der Kernel diesem Cache Speicherseiten übergeben, die verzichtbar sind, weil sich der Inhalt durch Nachladen vom Datenträger wieder beschaffen lässt. Da das allerdings langsam ist, versucht Clearcache die Daten im Speicher zu halten – etwa mit Hilfe des bei 2.6.39 integrierten Zcache, das als Cleancache-Backend fungiert und die Daten komprimiert. Beim Zusammenspiel mit dem Xen-Hypervisor kann Cleancache auch den Xen Transcendent Memory als Backend zum Ablegen von Daten nutzen. Der steht auch anderen Gästen zur Verfügung und kann doppelt gespeicherte Daten zusammenführen – das kann die Performance verbessern, wie eine im Commit-Kommentar verlinkte Präsentation erläutert. Weitere Hintergründe liefern die gute Cleancache-Dokumentation und der schon etwas ältere LWN.net-Artikel "Cleancache and Frontswap"

Zum Memory-Management-Code stießen die lange vorbereiteten Patches, die Peter Zijlstra unter dem Schlagwort "MM preemptibility" entwickelt hat und die die Funktion mmu_gather unterbrechbar machen, was Skalierbarkeit, Performance und Echtzeit-Eigenschaften verbessern kann (u. a. 1, 2, 3, 4, 5).

Staccato

• Der unter anderem beim Ein- und Ausschalten von Tracepoints oder Dynamic Debugging involvierte Code für Jump Label wurde umgebaut, um den Overhead durch solche Label zu verringern und diese einfacher nutzen zu können – Details liefert LWN.net im Artikel "Jump label reworked".
• Verschiedene Anwender können beim Einsatz des Function Tracers (Ftrace) nun jeweils unterschiedliche Funktionen filtern.
• Der Perf-Probe-Code zum Suchen nach Funktionsnamen bietet nun einen Fastpath; der kann diese Aufgabe erheblich beschleunigen, wie Messergebnisse im Commit-Kommentar zeigen.
• Eine schon in einige Stable-Kernel eingezogene Änderung am Cpufreq-Code beseitigt einen Fehler, der auf manchen Systemen zu einer leicht höheren Leistungsaufnahme geführt hat.
• Der Intel-IOMMU-Treiber unterstützt jetzt auch Super Pages mit Größen wie 2 MiB oder 1 GiB.
• Sysfs legt für SELinux jetzt den Pfad /sys/fs/selinux/ an, der langfristig den bisher für SELinux genutzten Mount-Punkt /selinux/ ersetzen soll.
• Durch einige Änderungen am Capabilites-Framework kann dieses nun Usermode-Helfern bestimmte Funktionen untersagen – etwa damit Anwender über die Capability CAP_NET_ADMIN keine Kernel-Module mehr laden können.
• Der Kernel bietet nun eine Reihe von mit "kstrtol_" beginnende Funktionen, um von Userland angelieferte Strings in Zahlenwerte zu verwandeln; die neue Funktion "strtobool" verwandelt Zeichenketten aus dem Userland in Boolean-Werte.
• Über den neuen Kbuild-Parameter "W=" lässt sich vorgeben, welche Art von Compiler-Warnungen beim Übersetzen ausgegeben werden. Es gibt drei Stufen; um alle zu aktivieren, muss man "W=123" angeben, was zu rund 90.000 Warnungen führen soll.
• Der Kernel bietet nun "Alarm-Timers". Ähnlich wie Hrtimers stoßen sie zu einem bestimmten Zeitpunkt eine Aufgabe an; die Alarm-Timer sorgen aber zusätzlich dafür, dass das System nötigenfalls auch dem Bereitschaftsmodus aufwacht. Aus dem Userspace lassen sie sich über das POSIX-Time-Interface nutzen. Die Android-Entwickler hatten eine ähnliche, Android Alarm Driver genannte Lösung mit einem anderen Userspace-Interface schon vor längerer Zeit entwickelt, damit beispielsweise Smartphones aus dem Suspend aufwachen, um an Termine zu erinnern. Einige Hintergründe zum Konzept liefert der Hauptautor der Alarm-Timers in einem LWN.net-Artikel.
• TREE_PREEMPT_RCU – eine von mehreren Kernel-Varianten für RCU (Read-copy-update), das den Datenzugriff auf Multi-Processor-Systemen synchronisiert – beherrscht jetzt das für den Echtzeiteinsatz wichtige Priority Boosting. Die Nutzung von RCU wurde weiter ausgebaut – auch die POSIX-Timer nutzen sie, wodurch laut Commit-Kommentar ein Micro-Benchmark erheblich flotter arbeitet. Der RCU-Code wurde zudem an vielen Stellen optimiert (siehe "Die kleinen Perlen"); eine der Änderungen führte zu einer größere Performance-Einbuße in einem Test, welche die Kernel-Hacker aber zum RC4 wieder aus der Welt geschafft haben.
• Einige Änderungen am Module-Loader (u. a. 1, 2, 3, 4) sollen das Laden von Modulen ein wenig beschleunigen.
• Die Dokumentation weist darauf hin, dass der Kernel alle Meldungen mit Zeitstempeln versieht, wenn man den Parameter "printk.time=1" übergibt.