Einleitung

Dieser Text entstand im Rahmen eines Seminars an der FH Wedel. Er soll die wesentlichen Merkmale der Prozessorganisation im Linux Kernel in der Version 2.4.x erläutern. Wesentliche Neuerung an diesem Kernel ist eine verbesserte Unterstützung der SMP Fähigkeit von Linux, somit soll diesem hier besondere Rechnung getragen werden.

Grundlegende Konzepte

Linux ist ein Multitasking Betriebssystem, d.h. ein Benutzer kann mehrere Programme zum gleichen Zeitpunkt laufen lassen und auch da System wird noch einige Programme starten, die einen produktiven Betrieb ermöglichen (z.B. lpd, der Druckerdemon). Auch ist es ein Multiusersystem, welches es mehreren Benutzern gleichzeitig erlaubt mit ihm zu arbeiten. Dies führt dazu, daß eine Vielzahl von Prozessen gleichzeitig auf dem System laufen werden. Damit ein Prozess läuft benötigt er im Regelfall eine CPU, die ihm die Rechenleistung zur Verfügung stellt. Das eigentlich komplizierte ist nun. daß man in einem aktuellen Rechner nur eine endliche Anzahl CPUs hat (bei den meisten PCs dürfte es ziemlich genau eine CPU sein), auf jeden Fall weniger CPUs als Prozesse.
Dies führt dazu, daß viele Prozesse warten müssen bis sie Rechenzeit bekommen. Dies ist auch nicht weiter tragisch, wenn man bedenkt, daß ein Editor zeitweilig sehr wenig zu tun hat außer auf weitere Benutzereingaben zu warten. Die Kunst ist es nun alle Prozesse möglichst sinnvoll zu sortieren und anzuordnen und zu bestimmen, wann welcher Prozess Rechenzeit bekommt und welche Prozesse warten können.
Ein weiteres Problem, welches sich hierbei stellt, ist daß das Programm welches entscheidet, welche Prozesse Rechenzeit zugeteilt bekommen (also ein Teil des Kernels: der Scheduler), ja auch selber CPU Leistung benötigt. Diese Zeit, die der Scheduler und andere Kernelprogramme benötigen um den administrativen Aufwand zu bewältigen, bezeichnet man als Overhead. Klares Ziel ist es den Overhead möglichst klein zu halten. Somit kommt es vor, daß auf besonders elegante Lösungen, die allerdings auch recht rechenintensiv sind verzichtet wird zugunsten von schlichteren, effizienteren Algorithmen.

Traditionell werden Prozesse als eine einzelne Sequenz von Intruktionen definierten, die in einem eigenen Adressraum ausgeführt werden. Diese Definition lässt sich so nicht ganz aufrechterhalten. Wie eingangs erwähnt, ist Linux ein Multiusersystem, wenn mehrere Benutzer nun einen emacs starten, so wäre es ineffizient, den Code mehrmals zu laden. Somit wird der Code nur einmal geladen und kann von allen Benutzern gebraucht werden. Katastrophal wäre es hingegen, wenn sich die Benutzer auch denselben Datenbereich teilen müssten, da nun jeder in dem Text des anderen herumpfuschen würde.
Somit hätten wir in diesem Fall also mehrere Prozesse, die sich denselben ausführbaren Code (emacs) teilen, die aber jeder auf einem eigenen Datenbereich arbeiten.
Linuxprozesse können in zwei Modi arbeiten: dem User- und dem Kernelmode. Die meiste Zeit arbeiten sie im Usermode. Hier haben sie allerdings nicht die Möglichkeit auf Funktionen des Kernels zuzugreifen, wie z.B. einen Handler für einen Hardware Interrupt. Tritt so ein Interrupt ein, beispielsweise um dem Programm zu melden, daß eine I/O Operation beendet wurde, so muß das Programm eine Routine des Kernels mit dem Namen interrupt handler aufrufen. Zu diesem Zweck springt es in den Kernelmode, behandelt den Interrupt und kehrt anschließend in den Usermode zurück.
Weiterhin ist zum besseren Verständnis der nachfolgenden Kapitel anzumerken, daß Linuxprozesse in einer Baumstruktur angeordnet sind. Jeder Prozess hat genau einen Elternprozess. Die einzige Ausnahme besteht in dem init Prozess der zur Bootzeit erzeugt wird, er ist der erste Prozess, also quasi der Urahn aller danach erzeugten Prozesse. Diese Struktur kann man sich sehr schön ansehen, wenn man das Kommando pstree in einer Shell aufruft.