0. Technische Aspekte von Mac OS X Inhaltsverzeichnis

Stichwort-Liste

• 0.1.1 Einleitung
• 0.1.2 Bestandteile des XNU-Kernels
• 0.1.3 Warum ein Hybrid-Kernel?
• 0.1.4 Exkurs: Mikrokernel
• 0.1.4.1 Mikrokernel-Nachteil
• 0.1.4.2 Mikrokernel-Vorteile
• 0.1.5 Anandtechs FUD
• 0.1.6 UNIX-Standards
• 0.1.7 Kernel-Schnittstellen
• 0.1.8 Ergebnis

0.1 Der XNU-Kernel von Mac OS X

Warum Linux als Kernel ein Nachteil wäre.

0.1.1 Einleitung

Gelegentlich liest man die falsche Behauptung, Mac OS X würde einen Mikrokernel nutzen. Tatsächlich wird jedoch ein Hybrid-Kernel verwendet: Der XNU-Kernel.

Dann wird in der Regel festgestellt, daß monolithische Systeme schneller sein können als Mikrokernel, was korrekt ist. Manche glauben, Linux wäre als Ersatzkernel zu empfehlen. Warum das nicht nur keinen Geschwindigkeitsvorteil in Mac OS X bringt, sondern sogar wichtige Vorteile beseitigen würde, beschreibe ich in diesem Artikel.

0.1.2 Bestandteile des XNU-Kernels

Der Kernel von Mac OS X ist der XNU-Kernel. Er besteht aus der Verschmelzung des Mach-Kernels mit dem 4.4BSD-Lite2-Kernel.

Die Mach-Komponenten des XNU-Kernels handhaben diese Aufgaben:

• Speicherverwaltung
• Mach-Nachrichten und Kommunikation zwischen Mach-Prozessen
• Gerätetreiber

Die BSD-Komponenten des XNU-Kernels handhaben diese Aufgaben:

• Verwaltung von Benutzern und Rechten
• Netzwerk
• Virtuelles Dateisystem
• POSIX-Kompatiblitätsschicht

0.1.3 Warum ein Hybrid-Kernel?

Apple hat den Mach 3.0-Mikrokernel genommen und mit BSD-Kernel-Komponenten in einen einzigen Kernel-Adreßraum gelinkt. Dies geschah aus Geschwindigkeitsgründen: Es ist schneller, direkte Aufrufe zwischen verlinkten Komponenten zu machen, als sie über Nachrichten kommunizieren zu lassen. Der Mach-Anteil des XNU-Kernels wird nicht als Mikrokernel genutzt.

Diese modulare Struktur ergibt ein robusteres und erweiterbareres System als es ein monolithischer Kernel, wie Windows einen hat und Linux einer ist, erlauben würde und vermeidet gleichzeitig die Geschwindigkeitsnachteile einer reinen Mikrokernel-Architektur, wie es ein purer Mach-Kernel ist.

Apples Mac OS X nutzt daher mit dem XNU-Kernel alle Vorteile eines Mikrokernels ohne den einzigen Nachteil, den ein Mikrokernel aufweist, zu übernehmen.

0.1.4 Exkurs: Mikrokernel

Warum sind Mikrokernel aber generell große Klasse, auch wenn sie in Reinform etwas langsamer sind?

Mikrokernel sind sehr modulare Sammlungen von leistungsfähigen betriebssystemneutralen Abstraktionen, auf die ein Betriebssystem aufgesetzt werden kann. Beim Mach sind diese Abstraktionen Tasks, Threads, Memory Objects, Messages und Ports. Diese Modularität erlaubt eine Skalierbarkeit, Erweiterbarkeit und Portabilität, die in monolithischen oder konventionellen Betriebssystemen nicht typisch sind.

0.1.4.1 Mikrokernel-Nachteil

Mikrokernel haben als Hauptziele Portabilität und Entkopplung vom darauf laufenden Betriebssystem. Einziger Nachteil: Mikrokernel sind aufgrund dieser Ziele nicht ganz so schnell wie monolithische Betriebssysteme, denn sie haben mehr Kommunikations-Aufwand.

Auf der anderen Seite werden monolithische Kernel aufgrund ihrer schieren Größe immer schwieriger zu optimieren. Mit jeder Folgeversion wachsen die Probleme, den Kernel effizient zu machen. In der Praxis sieht man das an Windows, welches mit jeder Version langsamer wurde, und an Linux, das ebenfalls jedesmal an Leistung verloren hat. Linus Torvalds bedauert, daß Linux riesig und aufgebläht ist und deshalb an Leistung verloren habe. Und Intel erkannte 2% Leistungsverlust pro Linux-Version.

Im Gegensatz dazu wurde Mac OS X mit jeder neuen Version deutlich schneller. Die Optimierung fällt hier leichter, denn der Kernel ist einer der kleinsten.

0.1.4.2 Mikrokernel-Vorteile

Mikrokernel schieben viele Betriebssystem-Dienste in den Benutzer-Adreßraum, die bei monolithischen oder konventionellen Betriebssystemen im Kernel gehalten werden. Dies hat viele Vorteile:

• Robustheit:
  Wenn ein Dienst (Service) Probleme macht, wird er neu konfiguriert und wieder gestartet, ohne das komplette Betriebssystem neuzustarten. Bei einem monolithischen Betriebssystem muß das Betriebssystem neu gestartet werden. Dadurch daß viele Dienste in komplett unabhängigen Speicherbereichen laufen, wird der Kernel durch Bugs und Fehlkonfigurationen wenig beeinträchtigt.
• Sicherheit:
  Da Dienste im Benutzer-Adreßraum laufen, haben sie nur eingeschränkt Zugriff auf Ressourcen, d.h. die Möglichkeit Mist zu bauen.
• Konfigurierbarkeit:
  Dienste können geändert werden, ohne das ganze System neu zu starten.
• Bessere Echtzeitfähigkeit:
  Mikrokernel sind sehr klein. Interrupts werden im Kernel-Modus unterbrochen. Die Unterbrechung dauert bei Mikrokerneln nicht so lange. Prozesse mit Echzeit-Anforderung können besseren Zugriff auf den Mikrokernel bekommen als andere Prozesse.
• Besseres symmetrisches Multiprozessing:
  Je mehr Dienste im Kernel laufen (bei Mikrokernel weniger als bei einem monolithischem), desto weniger effizient können zusätzliche Prozessoren genutzt werden, da der Kernel viel mehr mit der Verwaltung der Dienste zu tun hat. Einen monolithischen Kernel zur effizienten Nutzung von SMP zu bringen, ist sehr schwer. Ein System dagegen, was auf einem Mikrokernel läuft, der SMP bietet, hat es mit SMP leichter.

Ein weiterer Vorteil eines Mikro-Kernels ist seine Wartbarkeit. Da er klein ist per Design-Ziel, ist er gut pflegbar. Sämtliche Dinge, die nicht zur rudimentären Grundfunktion gehören, sind ausgelagert in den Userspace oder über Kernel-Schnittstellen als separate nachladbare Module angebunden, die ihrerseits wiederum aufgrund ihrer Größe leicht zu pflegen sind.

Der Linux-Kernel hingegen ist monolithisch, das heißt, möglichst alles wird direkt in den Kernel gepackt. Nachladbare externe Module sind bei Linux eher die Ausnahme. So werden Treiber beispielsweise in der Regel direkt in den Kernel compiliert. Ich habe das selbst schon für einen Graphikkarten-Treiber gemacht. Das Problem mit Linux ist also, daß viel zu viel in den Kernel gepackt wird und dieser große Kernel dadurch schwierig zu warten und zu optimieren ist.

Selbst Linus Torvalds hält Linux inzwischen für zu sehr aufgebläht, weil zu viele Features in den Kernel gepackt wurden. Linux wäre nicht das schlanke, kleine super-effiziente Stück Software, das er sich ursprünglich vorgestellt hatte. Laut Intel verlor Linux mit jeder Version 2% Leistung und ist innerhalb von zehn Jahren um 12% langsamer geworden. Im Gegensatz dazu ist OS X mit jeder Version schneller geworden.

0.1.5 Anandtechs FUD

Ich halte die Schlüsse, die AnandTech aus seinen Experimenten zieht, für zu gewagt. Sie selbst reden ja auch meist von "könnte" und an mehreren Stellen davon, daß sie keine harten Fakten hätten. Beispielsweise "We can't prove it […] we might be right, but it doesn't give us cold hard facts".

Sie haben keine harten Fakten, weil sie Prozeßerzeugung messen und nicht Thread-Erzeugung. Zwar besteht ein Prozeß aus mindestens einem Thread, aber die Geschwindigkeit zum Starten eines neuen Prozesses ist nicht allein auf die Geschwindigkeit zum Starten eines Threads zurückzuführen.

MySQL ist ein Prozeß mit vielen Threads. Der verwendete lmbench-Benchmark (der nichts mit MySQL zu tun hat) mißt jedoch keine Thread-Erzeugung, sondern nur Prozeßerzeugung. Und ob nur Thread-Erzeugung für MySQL wirklich das ist, was seine Geschwindigkeit stark beeinflußt?

Es wurde für die Experimente eine selbsterstellte Version von MySQL eingesetzt, die nicht die möglichen Optimierungen für Mac OS X verwendete. Es wurde ferner nicht die aktuelle Compiler-Version verwendet.

Ich bin eher der Meinung von rediculousfish, daß sie besser MySQL untersuchen sollten nach der Ursache. Wenn es ein Problem mit Threads auf Mac OS X gäbe, dann müßten andere Programme die gleichen Probleme haben.

0.1.6 UNIX-Standards

Um leicht Programme zwischen Betriebssystemen portieren zu können, sollte man auf zwei wesentliche Standards Wert legen: UNIX 03 und POSIX.

Mac OS X ist UNIX, weil es dem UNIX 03 Standard enstpricht. Außerdem ist Mac OS X voll POSIX-kompatibel. Linux entspricht nicht dem UNIX 03 Standard und Linux ist auch nicht vollständig POSIX-kompatibel. Linux spaltet sich eigenbrötlerisch ab, indem es einen eigenen Pseudo-Standard, die "Linux Standard Base", definiert.

Die volle Kompatibilität zu den UNIX-Standards schlechthin ermöglicht, beliebige UNIX-Programme auf Mac OS X mit minimalem Aufwand laufen zu lassen. Linux hingegen hat damit mehr Schwierigkeiten, weil es sich nicht an diese Standards hält.

0.1.7 Kernel-Schnittstellen

Mac OS X hat seit Version 10.4 Tiger offizielle Kernel-Schnittstellen. Damit haben Treiberhersteller eine verläßliche Entwicklungsgrundlage. Mit neuen Betriebssystem-Versionen bleiben bisherige Treiber kompatibel und müssen nicht immer wieder angepaßt werden.

Es wird seit einiger Zeit auch versucht, für Linux Kernel-Schnittstellen zu etablieren. Diese sind bislang jedoch weder durchgängig noch fest definiert. In der Regel müssen Treiber jedes Mal an neue Linux-Versionen, die relativ häufig erscheinen, angepaßt werden.

Damit ist Mac OS X ausgreifter: Es bietet für externe und interne Entwickler verläßlichere Schnittstellen.

0.1.8 Ergebnis

Linux würde als Kernel keinen Geschwindigkeitsgewinn bringen, weil er nicht schneller ist als ein Hybrid-Kernel. Linux würde als Kernel einige Verschlechterungen bringen, weil auf die Vorteile eines Mikrokernels verzichtet werden müßte, die ein Hybrid-Kernel jedoch nutzen kann.

Mit dem XNU-Kernel nutzt Mac OS X die besten Kernel-Techniken und vermeidet die bekannten Nachteile.

Außerdem würde man mit Linux auf offizielle Kernel-Schnittstellen und die Kompatibilität mit den internationalen UNIX-Standards verzichten.

---