Nach zähem Ringen haben die Befürworter einer präemptiven Echtzeitlösung – unter anderen auch unser Autor – die hohen Weihen empfangen. Der Preemptive Patch kommt in den offiziellen Kerneltree. Was verbirgt sich dahinter?

Der Begriff Echtzeit ist immer im Zusammenhang mit konkreten Anwendungen zu sehen, harte Echtzeit (hard Realtime) heißt, dass eine Anwendung vollkommen fehlschlägt, wenn die Deadline-Anforderungen nicht erfüllt werden. Weiche Echtzeit (soft Realtime) bedeutet bei einer Anwendung zwar Qualitätsverlust, aber keinen wirklichen Ausfall, wenn die Deadline-Anforderungen nicht erfüllt werden.

Linux ist in der Lage, viele Echtzeit-Anforderungen zu erfüllen, welche die jeweiligen Softwarelevels stellen – entweder von Interrupt-Service-Routinen auf Kernel-Ebene oder von Prozessen auf dem User-Level. Solange der Kernel Interrupts blockiert, kommen Interrupt- Service-Routinen nicht zum Zug. Im Kernel 2.4 sind diese Verzögerungen sehr kurz, bei einem 800-MHz-Pentium-III-System weniger als 60 Mikrosekunden. Das erfüllt bereits die meisten Echtzeit-Anforderungen für Interrupt-Level-Software, insbesondere bei modernen Systemkonfigurationen, bei denen extrem schnelle I/O-Anforderungen hauptsächlich von besonderer Hardware wie intelligenten I/O-Controllern, Micro-Controllern oder kundenspezifischer Hardware bedient werden.

Andere Anforderungen – andere Lösungen

In den wenigen verbleibenden Fällen, bei denen durch Interrupts blockierte Phasen nicht toleriert werden können, sind RTLinux und RTAI verfügbar. Hierbei handelt es sich um Sub-Kernel-Technologien, die für Software auf Treiberebene einfache multi-threaded Interrupt-Handling-Umgebungen erzeugen. Diese Umgebungen emulieren (virtualisieren) dann Interrupt-Management-Anforderungen von Linux und reduzieren so die längstmöglichen Zeiten, in denen keine Interrupts verarbeitet werden, von etwa 60 Mikrosekunden auf nur noch ungefähr zehn Mikrosekunden.

Moderne Echtzeit-Umgebungen enthalten typischerweise umfangreiche Steuerungs- und Überwachungs-Software im Echtzeit-Kontrollpfad. Solche Software liegt im User-Level. Stellen Sie sich etwa eine in Java geschriebene Echtzeit-Steuerungssoftware vor, die auf JVM läuft – ein zunehmend beliebtes Design. Ein solches System würde nie als Treiber implementiert sein.

Die Anforderungen an die Antwortzeiten von Anwendungen sind direkt an die Fähigkeit des Kernels gebunden, einen laufenden Prozess zu unterbrechen (Präemption) und sehr schnell auf einen neu entstandenen Prozess höherer Priorität umzuschalten.

Das Fehlen der Kernel-Präemption bei Linux bedeutet, dass lange Systemaufrufe die Ausführung von Anwendungsprozessen hoher Priorität für eine relativ lange Zeit verzögern, bis zu mehreren zehn Millisekunden bei einem 2.4-Kernel. Inzwischen gibt es einen Kernel-Präemption-Patch, der schon heute diese Zeit auf ein bis zwei Millisekunden reduziert, weitere Verbesserungen für die Zukunft sind geplant.

Profitieren von Multiprozessor-Systemen

Der Patch nutzt die SMP-Spinlocks, die für symmetrische Multiprozessorsysteme notwendig sind. Neuer Kernelcode, der korrekt in einem SMP-Kernel funktioniert, erfordert keine zusätzlichen Änderungen im präemptiven Kernelpatch. Das bedeutet außerdem geringe Kosten, was den Betreuungsaufwand des Patches gegenüber der sich entwickelnden Linux-Basis betrifft.

Ob ein System, das diese Reaktionsanforderungen garantiert, als Echtzeitsystem betrachtet werden kann oder nicht, ist eher eine Frage der Positionierung als eine der Technik. Der Level an Verbesserung bei Linux führt von Einschätzungen wie “problematisch” bis zu “sehr akzeptabel” für die breite Mehrheit der Anwendungen, die Echtzeit-Anforderungen haben (weich oder hart).

Einige Embedded-Linux-Firmen haben sich verpflichtet, für Langzeit-Verfügbarkeit und Support dieser Fähigkeit zu sorgen und diese auf allen wichtigen Zielplattformen zu unterstützen. Eine weitere geplante Verbesserung soll eine alternative Semaphore-Implementierung sein, die Prioritätenvererbung verwendet. Zudem wird weiterhin daran gearbeitet, lange im Spinlock gehaltene Bereiche zu verfeinern.

Ebenfalls versucht man zurzeit, Auswirkungen des Durchsatzes (positive wie negative) auf eine Vielzahl von Arbeitsbelastungen zu charakterisieren. Das Ergebnis wird wahrscheinlich schon in Kürze verfügbar sein.

Abbildung 1: Kevin Morgan hält den Preemptive Patch für die meisten Echtzeitanwendungen für ausreichend.

Für und Wider Präemption

Vereinfacht gesagt bedeutet das Verändern eines Uniprozessor-Kernels, um internes Re-Entrancy-Management hinzuzufügen, allerdings mehr Code und folglich mehr Zeit. Oberflächlich betrachtet hat ein präemptiver Kernel also einen reduzierten Durchsatz.

Der Kern des Durchsatz-Problems ist die Frage nach einem ausgewogenen Systemdesign und nach den Zielen des gesamten Designs. Wie wichtig ist ein Linux mit kurzen Antwortzeiten? In der Welt von Streaming Media spielt die Reaktionzeit eine enorm wichtige Rolle. Eine Demonstration des präemptiven Kernels bei einfachen Audioprozessen zeigt, dass sogar solch eine relativ triviale Belastung auf einem nicht-präemptiven Linux Verzögerungen bei den User-Prozessen auslöst, die bereits über der Wahrnehmunssschwelle des menschlichen Ohrs liegen, die Audio-Pannen sind also hörbar. Mit Präemption werden diese Verzögerungen weitgehend reduziert und es kommt zu keinen hörbaren Ausfällen mehr.

Anwendungsfall Streaming Media

Bei einigen Entwicklern stößt der präemptive Kernel wegen der Durchsatz-Probleme auf Kritik. Andere opponieren gegen Präemption, weil die wachsende Komplexität die Entwicklungsarbeit am Kernel erschwert. Dieses Argument trifft jedoch nur scheinbar zu, da der beschriebene Ansatz der Präemption den Vorteil des bereits erforderlichen und installierten SMP-Lockings hat. So entsteht keine zusätzliche Komplexität. Jedes Linux-Kernel-Engineering muss bereits SMP-Anforderungen berücksichtigen.

Einige sind gegen kontinuierliches Verfeinern des SMP-Lockings, das auf SMP-Systemen mit mehr CPUs die Skalierbarkeit verbessert. Feingranulareres SMP-Locking hat jedoch auch den positiven Nebeneffekt, die Präemptions-Off-Zeiten in einem präemptiven Kernel spürbar zu reduzieren.

Die Fähigkeit zur Präemption beim 2.4-Kernel führt schon jetzt zu dramatischen Verbesserungen bei den Reaktionszeiten von User-Prozessen. Obwohl eine weitere Verbesserung durchaus vorteilhaft wäre, ist der gegenwärtige Zustand bereits von ungeheurem Wert. Daher kann man über das Für und Wider, SMP-Skalierungen in Linux zu verbessern, auch relativ unabhängig von Verbesserungsmöglichkeiten der Präemptions-Fähigkeit diskutieren.

Verantwortung gegenüber der Community

Embedded-Linux-Firmen sind verantwortlich gegenüber den Open-Source-und Linux-Communities sowie den Produktentwicklern bei Embedded-Systemen. Die Firmen müssen innovativ sein, Entwicklungen früh und oft herausbringen – und sie öffentlich diskutieren und damit andere Ideen und Code einbringen. Als Unternehmen müssen sie ihr Bestes geben, um aus Linux eine brauchbare Plattform für das Design und die Implementierung von Embedded-Systemen zu machen. Das wird auch ihren Kunden nützen.

Die Community rund um den Linux-Kernel ist groß und vielfältig, auf jeder technischen Ebene gibt es lebhafte Diskussionen und Debatten. Das ist bei der präemptiven Kerneltechnologie nicht anders. Der Embedded-Systems-Markt und die Linux-Community selbst werden im Laufe der Zeit über die relativen Verdienste der präemptiven Kerneltechnologie entscheiden. (uwo)