Interruptebene

Aktivitäten auf dieser Ebene haben keine korrespondierende Task-Struktur, da sie keinem Prozeß zugeordnet sind, sondern vielmehr auf Hardware-Ereignisse reagieren. Aus diesem Grund werden sie auch bevorzugt ausgeführt, d.h. Prozeßaktivitäten werden erst nach Ausführung aller Aktivitäten auf der Interruptebene fortgesetzt.

Aber auch auf der Interruptebene sind nicht alle Threads gleich priorisiert. So kann der Interrupt-Handler bei zugelassenen Unterbrechungen jede Aktivität von der CPU verdrängen. Für den Zeitraum der Bearbeitung eines Interrupts sind weitere Unterbrechungen auf dieser CPU oft^2.5 gesperrt, so daß die nötigen Aktionen in drei Gruppen unterteilt werden:

Kritisch

sind interrupt acknowledgement und Reprogrammierung des PIC bzw. Gerätecontrollers. Unterbrechungen dürfen nicht auftreten.

Nicht kritisch

sind Aktionen, die Datenstrukturen aktualisieren und schnell beendet werden können. Unterbrechungen können zugelassen werden^2.6.

Nicht kritisch & aufschiebbar

sind Aktionen wie langwierige Kopierperationen innerhalb des Hauptspeichers, die möglicherweise blockierende Funktionen benötigen.

Im Linuxkern werden Aktionen der ersten beiden Gruppen unter dem Begriff top half zusammengefaßt und sind Bestandteil des registrierten Interrupt-Handlers. Die letzte Gruppe macht die bottom half (BH) aus, deren Ausführung zu einem späteren Zeitpunkt stattfinden kann. Abb. 2.7 präzisiert den in Abschnitt 2.2 beschriebenen Aufbau für Linux-Gerätetreiber.

Abbildung: Prozeß- und Interruptebene im Linuxkern

Die Aktivitäten der Interuptebene können nun direkt von einem Interrupt angestoßen werden und somit in der Top Half liegen oder zu einem späteren Zeitpunkt (durch die Top Half angestoßen) als Bottom Half ausgeführt werden.

Während der fortschreitenden Entwicklung des Linuxkerns wurde dieses Konzept stetig ausgefeilt und neben den old-style Bottom Halves existieren auch neuere deferred activities:

Bottom Halves

implementieren die Ursprungsidee, werden dabei aber streng serialisiert. D.h. auch in SMP-Systemen ist stets nur eine BH zu einem Zeitpunkt aktiv, um der Annahme zu entsprechen, daß keine weitere BH parallel Daten verändert.
Diese Funktionalität stammt noch aus der nicht-SMP Zeit von Linux und ist, wie man leicht erkennen kann, nicht besonders gut geeeignet für Plattformen mit mehreren Prozessoren.

Tasklets

erweitern das BH-Konzept dahingehend, daß nun Typen von deferred activities existieren, welche serialisiert werden. Es können also in Multiprozessor-Systemen mehrere Tasklets gleichzeitig ausgeführt werden, wenn sie nicht vom gleichen Typ sind.
Tatsächlich sind alle old-style Bottom Halves ein Tasklettyp in Linux 2.4, so ist ihre Serialisierung bewahrt und Parallelität in Bezug auf new-style Tasklets gewährt.

Softirqs

repräsentieren die Idee, daß deferred activities vollständig parallel ablaufen können, also insbesondere auch verschiedene Instanzen ein und derselben Aktivität. Diese Freiheit erzwingt aber reentrante Funktionen und intelligente Sperren.
Wie vorab schon erwähnt, ist die Komponente, welche von der SMP-Fähigkeit der Version 2.4 des Linuxkerns hauptsächlich profitiert, der Netzwerk-Protokollstack. Beide Pfade -- Senden und Empfangen -- werden hier als softirqs implementiert (siehe [T$^+$01] Datei net/core/dev.c: net_rx_action() bzw. net_tx_action()), sind also reentrante Funktionen.

In Zukunft sollen die BHs allmählich verschwinden und durch Tasklets ersetzt werden. Die softirqs sollen aber wichtigen Kernaktivitäten vorbehalten bleiben und sind bisher nur für den TCP/IP-Stack geplant.