Linux-Trends/Deutliche Verbesserung der System-Performance vor allem zugunsten von Servern

Linux-Kernel 2.6: Kampfansage an Unix

04.06.2004
Seit einem halben Jahr gibt es für Linux einen stark überarbeiteten Kern. Von dessen Änderungen profitieren insbesondere Server-Anwendungen. Die Details der technischen Verbesserungen lassen erkennen, wie sich das Betriebssystem positioniert und wohin die Reise geht. Es wird zu einer ernsten Konkurrenz für Unix. Von Eva-Katharina Kunst und Jürgen Quade*

Zwei Jahre hat die Entwicklung am Kernel 2.6 gedauert, drei Jahre waren seit der Veröffentlichung des Vorgängers 2.4 ins Land gezogen. Während dieser eine lange Phase der Konsolidierung durchlaufen musste, galt sein Nachkomme von Anfang an als stabil. Nicht verwunderlich also, dass Suse, Red Hat und Mandrake ihn bereits in ihre Distributionen aufgenommen haben.

Wer von der jüngsten Linux-Kernel-Version (aktuell: 2.6.6) spektakuläre Neuerungen erwartet, wird auf den ersten Blick enttäuscht. Viele der wesentlichen Veränderungen bleiben dem Auge des Durchschnittsanwenders verborgen. Zu spüren sind eine höhere Performance, und bekannt ist die erweiterte Skalierbarkeit.

Dass das Pinguin-System besser skaliert, lässt sich an nackten Zahlen ablesen: Server-seitig unterstützt Linux jetzt 64 statt bisher 16 Prozessoren und auf 32-Bit-Systemen 64 GB statt bisher 16 GB Hauptspeicher. Damit auch Maschinen mit mehreren Dutzend oder gar hundert CPUs besser skalieren, haben die Entwickler in Kernel 2.6 erstmals Numa-Support (Non-Uniform Memory Access) implementiert. Numa regelt den konkurrierenden Zugriff vieler Prozessoren auf den Speicher.

Damit empfiehlt sich Linux einmal mehr als Plattform für anspruchsvolle, unternehmenskritische Anwendungen, die eine große Arbeitslast erzeugen - und besetzt zunehmend eine Domäne, die einst den Unix-Konkurrenten HP-UX, Solaris und AIX vorbehalten war. Doch auch für Anwender eingebetteter Systeme ist der Kernel 2.6 attraktiv. Er unterstützt mehr Plattformen und Prozessoren, darunter erstmals solche, die keine Memory Management Unit (MMU) besitzen.

Wie jedes Kernel-Release hat die Version 2.6 zu ausgiebigen Testläufen in verschiedenen Umgebungen angeregt. Dabei überzeugte es insbesondere in seiner Funktion als Server. Die meisten Messungen ergaben signifikante Geschwindigkeitssteigerungen im Vergleich zu Version 2.4.

Gründe der verbesserten Performance

Die verbesserten dynamischen Systemeigenschaften lassen sich am besten am Zeitverhalten ablesen. Geht es um das Abspielen von Musik oder von Videos, kann der Zwo-Sechser auftrumpfen. Die Interrupt- und vor allem die Task-Latenzzeiten sind im Mittel um den Faktor zehn besser als zuvor - im Durchschnitt. Denn das Verhalten im Worst und auch im Best Case ist nur marginal verbessert worden. Der Einsatz von Linux in harten Echtzeitumgebungen ist nach wie vor nur in Kombination mit einer Echtzeiterweiterung (zum Beispiel RTAI oder RT-Linux) möglich.

Für die verbesserte Performance und das gute Zeitverhalten lassen sich eine Reihe von Ursachen ausmachen. Linus Torvalds beispielsweise hat den bereits für Kernel 2.4 verfügbaren "Preemption Patch" in den Kernel übernommen. Die Folge: Fast jede Systemfunktion kann unterbrochen werden, nur noch sehr wenige Codeteile sind durch Spinlocks vor Unterbrechungen geschützt.

Darüber hinaus ist die interne Systemfrequenz - quasi der Herzschlag des Kernels - von 100 Hertz auf 1000 Hertz erhöht. Der neue Kernel tickt in jeder Millisekunde einmal. Weil mehr Unterbrechungen zugelassen werden, erfolgt die Reaktion auf Ereignisse direkter. Leistungsschwächere Systeme indes müssen einen geringen Performance-Verlust in Kauf nehmen, der aktuelle und schnelle Systeme nicht betrifft.

Auch der neue Scheduling-Algorithmus hat einen wesentlichen Anteil an besserer Performance und Reaktionsfreudigkeit des Kernels. Der Name ist Programm: O(1) Scheduler. In der Informatik steht das Landau-Symbol "O" für die Komplexität eines Algorithmus. Entsprechend lässt sich ablesen, dass die Rechenzeit für die Prozessauswahl im Kernel konstant bleibt - wie viele Prozesse lauffähig sind, spielt keine Rolle mehr. Damit nicht genug: Ein weiteres Gimmick des Schedulers besteht darin, die Interaktivität eines Rechenprozesses bei der Verteilung der Rechenzeit einzubeziehen. Hiervon profitieren Prozesse, die viele Ein- und Ausgaben tätigen, typischerweise Desktop- und Multimedia-Applikationen.

Besonders gründlich haben sich die Kernel-Entwickler das I/O-Subsystem vorgeknöpft. Zugriffe auf Blockgeräte lassen sich nunmehr durch einen I/O-Scheduler optimieren. Während für die meisten Einsatzfälle der standardmäßig vorgesehene "Anticipatory Scheduler" ausreicht, wird der Entwickler eingebetteter Systeme den schlanken "Deadline-Scheduler" beim Plattenzugriff vorziehen.

Weniger sichtbar, deswegen aber nicht weniger wichtig ist eine weitere Veränderung im Kernel. Timerticks - im Linux-Kernel "Jiffies" genannt - werden jetzt in einer 64-Bit-Variablen gezählt. Während es im 2.4er Kernel mit dortigem 32-Bit-Zähler bereits nach 497 Tagen zum Überlauf kam, müsste der Anwender eines 2.6er auf dieses Ereignis schlappe 584 Millionen Jahre warten. Allerdings haben die Kernel-Entwickler den Zähler so vorinitialisiert, dass der erste und wohl einzige Überlauf bereits nach fünf Minuten vonstatten geht; eine erzieherische Maßnahme für unerfahrene Treiberprogrammierer. Ein Zählerüberlauf, der kritische Folgen nach sich ziehen kann (nicht muss), ist vor allem im Bereich der eingebetteten Systeme bedenklich. Im Büro und in den Server-Räumen wird eine Uptime von mehreren Jahren bislang nur selten erreicht.

Sicherheit wird groß geschrieben

Natürlich hat der neue Kernel auch in puncto Sicherheit einiges zu bieten. Erweitertes Firewalling und Verschlüsselungsalgorithmen im Kernel sind nur zwei Stichworte. Wesentlich für den Anwender ist die Integration von "IPsec": Das lästige Patchen des Kernels zum Aufbau eines Virtual Private Network (VPN) entfällt. Mit den "Linux Security Moduls" haben die Entwickler zudem eine neue Schnittstelle implementiert, mit der sich der Aufruf und die Abarbeitung von System-Calls anhand spezifischer Regeln überwachen lassen. Es ist beispielsweise denkbar, dass der Superuser sich nur dann als solcher einloggen kann, wenn er einen ganz spezifischen USB-Stick eingesteckt hat. Erste Security-Policies - entwickelt von der US-amerikanischen Sicherheitsbehörde NSA - existieren bereits (www.nsa.gov/selinux). Mit weiteren ist zu rechnen.

Die Open-Source-Gemeinde hat nicht nur Code modifiziert oder zum Kernel hinzugefügt, sondern sich auch von Bekanntem getrennt. Das trifft insbesondere auf Treiber für diejenige Hardware zu, die aufgrund ihres Alters exotisch geworden ist. Noch nicht vollzogen, aber bereits angekündigt ist die Trennung des Device-File-Systems vom Kernel.

Das Device-File-System war angetreten, ein 30 Jahre altes Unix-Problem zu lösen: die Limitierung des Systems auf maximal 256 Treiber mit jeweils maximal 256 unterstützten Geräten. Allerdings hat das Device-File-System die Erwartungen nicht erfüllen können. Der Code ist zu umfangreich und gilt in Entwicklerkreisen als nicht ausgereift. Zunächst sah es so aus, als würde IBM weiterhin nur mit Tricks vier bis fünftausend Festplatten an einen Linux-Rechner anschließen können.

Doch Linus Torvalds hat direkt vor der Veröffentlichung des Kernels die für die Limitierung verantwortlichen Major- und Minor-Nummern durch eine Gerätenummer ersetzt. Diese neue Gerätenummer ist 32 Bit breit. Im Vergleich dazu: Die Major- und die Minor-Nummern sind jeweils 8 Bit breit. Um damit nicht sämtliche Treiber und auch Anwendungsprogramme obsolet werden zu lassen, hat Torvalds ein Mapping zwischen Geräte- sowie Major- und Minor-Nummern implementiert. Jetzt können in einem System 4095 Treiber mit jeweils einer Million Geräten arbeiten. Allerdings ist dies eine Eigenschaft, die zwar im Kernel, noch nicht aber auf Anwendungs-ebene unterstützt ist. Bis die Systemprogramme nachgezogen haben, wird es jedoch nicht lang dauern.

Das "alte" Device-File-System hat nicht nur die Zahl der möglichen Treiber in einem System erhöht, sondern darüber hinaus versucht, für Ordnung im Urwald der Gerätenamen zu sorgen. Für Kernel 2.6 fällt diese Aufgabe "udev" zu. Udev (A Userspace Implementation of devfs) verlagert die Basisfunktionalität des Device-File-Systems aus dem Kernel in den User-Space. Es ermöglicht das dynamische Erzeugen und Entfernen der so genannten Gerätedateien. Wer beispielsweise eine Musik-CD von Chopin ins Laufwerk schiebt, muss nicht mehr auf das Gerät "/dev/cdrom" zugreifen, sondern kann sogleich "Chopin" anklicken.

Technisch hat erst Kernel 2.6 udev ermöglicht. Es benötigt nämlich das Gerätemodell, eine neue Komponente dieses Kernels. Im Gerätemodell sind die Informationen über die Geräte sowie über die Verschaltung der Geräte (die physikalische Struktur der Hardware) und der zugehörigen Treiber abgelegt. Anwender und Administratoren können auf diese Information über das neue Sys-File-System, die externe Repräsentation des Gerätemodells, zugreifen. Das Sys-File-System ist - ebenso wie das Proc-File-System - ein virtuelles Dateisystem, bei dem die Informationen dynamisch (also erst beim Zugriff) erzeugt werden und nicht statisch auf einem Hintergrundspeicher wie beispielsweise der Festplatte abgelegt sind.

Großes Potenzial im Gerätemodell

Das Gerätemodell war ursprünglich entwickelt worden, um ein funktionierendes Power-Management zu ermöglichen. Denn kennt man die physikalische Verschaltung der Geräte an den Bussystemen, lassen sich die einzelnen Komponenten bei Bedarf von außen nach innen abschalten. Dabei haben die Entwickler schnell erfasst, welch großes Potenzial die Technik bietet. Es gilt unter Beobachter schon heute als sicher, dass das neue Gerätemodell in den folgenden Kernel-Versionen eine zentrale Rolle spielen wird.

Und wo bleibt der Desktop? Andrew Morton, Maintainer des 2.6er Kernels und rechte Hand von Linus Torvalds, konstatiert: "Wir haben Server-seitig sehr viel Arbeit investiert, dort war es am notwendigsten. Für Desktops musste nicht viel getan werden. Kernel 2.4 war in dieser Hinsicht bereits ausgezeichnet - abgesehen von der Geschichte mit den Applikationen." Durch kürzere Antwortzeiten, die Interaktivität und das Geräte-Management profitiere jedoch auch der Desktop vom neuen Kernel, so Morton.

In erster Linie hat Kernel 2.6 allerdings eines bewiesen: Unternehmenstauglichkeit. Geht es um unternehmenskritische Anwendungen, spielt Linux mittlerweile in der gleichen Liga wie kommerzielle Unix-Varianten und dürfte für deren Anbieter zu einer echten Bedrohung werden. Kernel 2.6 hat das Fundament für den Einsatz im Datacenter, als Web-Server oder File-Server verbessert - ein Trend, der sich noch verstärken wird. Darüber hinaus wird sich das Bemühen der Entwickler, in den Embedded-Markt vorzudringen, fortsetzen.

Nach einem halben Jahr mit Kernel 2.6 rückt die Integration neuer Features in den nächsten Entwickler-Kernel - mit Nummer 2.7 - in den Vordergrund. Was folgt, ist das erneute Warten auf das nächste große Release. Wird es den Namen 2.8 tragen oder gar den "Quantensprung" auf Versionsnummer 3.0 vollziehen? Für den 19. bis 20. Juli ist ein Gipfeltreffen der Kernel-Entwickler (Kernel-Summit) im kanadischen Ottawa anberaumt. Hier fällt wahrscheinlich der Startschuss für die Arbeiten am künftigen Kernel. (ls)

*Eva-Katharina Kunst ist freie Journalistin in Kempen. Jürgen Quade ist Professor für technische Datenverarbeitung an der Hochschule Niederrhein in Krefeld.

Hier lesen Sie ...

- welche neuen technischen Eigenschaften des Linux-Kernels 2.6 welche Vorteile mit sich bringen;

- warum die Neuerungen besonders für Linux auf Servern von Vorteil sind;

- wodurch sich für die Anwendungsentwicklung neue Möglichkeiten ergeben;

- was schon hindeutet auf die Features der nächsten Kernel-Generation.

Kernel 2.4 und 2.6 im Vergleich

Eigenschaft / Kernel 2.4 / Kernel 2.6

Maximale Zahl CPUs (x86) / 16 / 64

Maximaler Hauptspeicher (x86) / 16 GB / 64 GB

Unterstützte Prozessorarchitekturen / 18 / 20

Multiprozessor- Architekturen / SMP / Numa, SMP

Zeitbasis (Hertz) / 100 / 1000

Maximale Anzahl Treiber / 255 / 4095

Maximale File-System-Größe / 2 TB / 16 TB

Unterstützung für CPUs ohne MMU / nein / ja

IPsec-Unterstützung im Kernel / nein / ja