Kernel-Log: Linux 2.6.35 nimmt Gestalt an

Linux 2.6.35 soll mehr Netzwerk-Durchsatz liefern, die Turbo-Core-Funktion moderner AMD-Prozessoren unterstützen und bei Bedarf Arbeitsspeicher defragmentieren. Auf der LKML sorgt derweil eine Diskussion um die Aufnahme einiger von Google für Android entwickelte Patches für ein erhöhtes Mail-Aufkommen.

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

Zwei Wochen nach der Freigabe von Linux 2.6.34 hat Linus Torvalds in der Nacht von Sonntag auf Montag die erste Vorabversion von Linux 2.6.35 veröffentlicht und damit die Aufnahme der größten Änderungen für die in zirka zehn Wochen erwartete Kernel-Version abgeschlossen. Die Merge Window genannte Phase dauerte dieses Mal wieder 14 Tage, nachdem das Zeitfenster bei Linux 2.6.34 etwas kürzer war, was zu Verwirrung bei einigen Subsystem-Verwaltern geführt hatte.

Wie üblich wird die nächste Version der Hauptentwicklungslinie wieder haufenweise Änderungen und Verbesserungen an Infrastruktur und Treibern bringen. Durch einige von Google-Entwickler Tom Herbert eingebrachte Änderungen beherrscht das Netzwerk-Subsystem des Kernels nun etwa Receive Packet Steering (rps) und Receive Flow Steering (rfs) – zwei Techniken, die die Schritte zur Verarbeitung von empfangenen Netzwerkpaketen geschickter auf die verfügbaren Prozessorkerne verteilen, um den Durchsatz zu steigern und Latenzen zu senken.

Durch Memory Compaction soll der Kernel bei Bedarf die Fragmentierung des Arbeitsspeichers reduzieren können – so lassen sich größere Bereiche freien Speichers schaffen, die sich mit großen Speicher-Pages nutzen lassen, was den Verwaltungs-Overhead klein hält. Linux 2.6.35 bringt zudem volle Unterstützung für die Turbo Core genannte Funktion, mit der neuere AMD-Prozessoren ihren Takt bei Teilauslastung steigern.

Weiter ausgebaut haben die Kernel-Hacker die bei Linux 2.6.34 noch rudimentäre Unterstützung für die Stromsparfunktionen bei Radeon-Grafikchips. Ferner führt der Cpuidle-Code nun besser Buch über die Systemauslastung, damit er nicht durch zu aggressive Nutzung der zur Laufzeit nutzbaren Prozessor-Schlafmodi den Datendurchsatz reduziert.

Wie üblich wird das Kernel-Log in den kommenden Wochen in c't und auf heise open über diese und hunderte anderer Neuerungen von Linux 2.6.35 berichten. Insgesamt gab es zwischen 2.6.34 und 2.6.35-rc1 im Hauptentwicklungszweig 8113 Commits, die laut Diffstat 609.506 Zeilen Quellcode einfügen und 270.035 entfernen. Ungefähr zwei Drittel der Quellcodeänderungen modifizieren Treiber-Code.

Die auf Linux-Hardware-Themen spezialisierte Webseite Phoronix will bei Geschwindigkeitstest festgestellt haben, dass der Linux-Kernel des Hauptentwicklungszweigs seit einigen Tagen signifikant langsamer arbeitet als ältere Kernel. Die Webseite widmet der Problematik einen fünfseitigen Artikel unter der Überschrift "The Huge Disaster Within The Linux 2.6.35 Kernel".

Das ist ziemlich viel Aufwand für eine Vorabversion von 2.6.35, denn bis dieser Kernel erscheint, dürften noch knapp zwei Monate verstreichen – zum Zeitpunkt der Tests gab es noch nicht einmal Vorabversionen von 2.6.35, wie die Phoronix-Macher bereits im ersten Absatz anmerken. Die Kernel-Entwickler haben also noch reichlich Zeit, eventuelle Performance-Probleme zu beseitigen.

Berichte über Performance-Probleme bei Vorabversionen finden sich auf der Linux Kernel Mailing List (LKML) ohnehin zuhauf, denn sie werden alle paar Wochen oder Monate von Testern bei AMD, IBM, Intel sowie anderen Firmen und Institutionen gefunden. Das ist aber selbst auf Linux spezialisierten Medien meist keine oder nur eine kurze Erwähnung wert, weil es für die Performance-Unterschiede entweder gute Gründe gibt oder die Probleme bis zur Freigabe der jeweiligen Kernel-Version sowieso beseitigt werden.

Außerdem kann man wie bei jeder Messung über die Relevanz der Tests streiten – Phoronix hat in dieser Hinsicht unter Kernel-Entwicklern nicht unbedingt den besten Ruf (etwa 1, 2, 3). So wurden die jetzigen Tests mit zwei Nettops durchgeführt, in denen schwachbrüstige Atom-Prozessoren stecken. Beide zeigten Einbrüche bei der Performance, der deutlichste trat jedoch bei dem Nettop mit Poulsbo-Chipsatz auf, den viele Linux-Anwender aufgrund der problematischen Treiber-Situation meiden. Das Gerät nutzte zudem das experimentelle, noch nicht für den Produktiveinsatz geeignete Dateisystem Btrfs.

Die Kernel-Entwickler scheinen über das Problem bislang noch nicht informiert worden zu sein, konnten es also auch noch nicht kommentieren – zumindest findet eine Suche nach Phoronix bei bugzilla.kernel.org und auf der LKML bislang keine relevanten Einträge.

[Update 20100601245] Mittlerweile wird die Problematik auf der LKML diskutiert und eine mögliche Ursache genannt, die bereits behoben wurde. Dave Airlie kritisiert in dem Rahmen die Arbeitsweisen von Phoronix ganz allgemein, während Ingo Molnar durchblicken lässt, dass man sich mit solch einer Berichterstattung arrangieren muss. [/Update]