Verbesserung der Reaktivität des Linux-Kernels Steffen Mazanek

Gliederung -Einführung: Was ist real-time Fähigkeit, wofür braucht man sie und was ist zur Zeit mit Linux in diesem Bereich möglich? -Wie kann man die Reaktivität verbessern? - Preemption Patch - Low Latency Patch - RTLinux -Ausblick

Was ist real-time? IEEE: a real-time system is a system whose correctness includes its response time as well as its functional correctness Diese Definition lässt viele Interpretations- spielräume Deshalb: Einteilung in hard und soft real- time

Arten von real-time Systemen Hard real-time: Garantierte anwendungsabhängige worst-case Reaktionszeiten (nicht unbedingt kurz, aber sehr deterministisch) Soft real-time: Rechtzeitigkeit wird benötigt, aber Scheitern bleibt ohne schwerwiegende Folgen (evt. Qualitäts- verluste)

Wer benötigt real-time? Systeme mit hoher Verantwortung, z.B. - Gefahr für Menschenleben - Industrielle Automation Steigender Bedarf ausgelöst durch Anwendungen der Vernetzung, z.B. - Voice-over-IP Im Bereich Multimedia, z.B. - Video streaming

Linux und real-time? Linux ist kein real-time Betriebssystem - Andere Entwurfskonzepte mit teilweise konkurrierenden Zielen - Im Sinne einer weiteren Verbreitung, versucht man, die Qualitäten in diesem Bereich zu verbessern, so dass ein Einsatz etwa in embedded systems o.ä. möglich wäre Dank open source möglich und teilweise schon realisiert, entweder direkt im Kernel oder mit entsprechenden Patches

Was der aktuelle Linux Kernel leistet Zeitvorgaben im Millisekundenbereich werden standardmäßig nicht eingehalten, aber soft real- time ist kein Problem Kritische Bereiche werden unter Interruptsperre abgearbeitet - Kernel ist nicht preemptiv Langwährende Systemaufrufe halten hochpriore Benutzerprozesse auf Quelle für Indeterminismus der Antwortzeiten Thread scheduling policies - SCHED_FIFO, SCHED_RR, SCHED_OTHER - Nicht gerade fein-granuliert und parametrisierbar

Scheduler Latency Latency: - Allg: Intervall zwischen Stimulus und Reaktion (meist stochastisch) - hier: Zeit, die nach Ereignis vergeht, bis betroffener Thread den Prozessor erhält (PDLT) Was passiert in dieser Zeit? - Interrupt ISR Interrupt Handler des Device Drivers (aktiviert betroffenen Thread) need_resched flag des current task … scheduling (muss diesen Thread aber nicht auswählen) … Thread läuft

Möglichkeit I: RTLinux Läuft außerhalb vom eigentlichen Kernel - ist eigenständiges RT OS - Linux als niedrigst-priorer RT-Task Besitzt das System und kann auf Ereignisse nahezu sofort reagieren Software emuliert Interrupt Controller transparent für Linux (Virtuelle Maschine) Nachteile: zwei APIs, verbessert nicht die real-time Fähigkeiten von Linux, Overhead

Möglichkeit II: Kernel Preemption Nicht im aktuellen Standard Kernel - im 2.5er Entwicklerkernel optional auswählbar Kernel Preemption Patch verfügbar: - von Monta Vista entwickelt - von Kernel Maintainer Robert Love gewartet und weiterentwickelt

Kernel Preemption Patch Konzepte/Änderungen I Veränderte Implementierung von Spinlocks - SMP Synchronisation Preemption Lock, kontrolliert Wiedereintritt in kritische Bereiche Modifizierte Interrupt-Behandlung - erlaubt Re-Scheduling sofort danach, selbst wenn unterbrochener Prozess im System- Modus war (Ausnahme: dessen Region ist preemption locked)

Kernel Preemption Patch Konzepte/Änderungen II Andere Implementierung von spin unlock - System wird wieder in preemptable state gebracht und es wird sofort geprüft, ob context switch nötig ist Angepasste Kernel build definition - Speziell Uniprozessor Systeme müssen auch spin locks aktivieren

Bewertung Forderung: sehr kurze kritische Regionen Reaktivität drastisch gesteigert - Durchschnitt und worst case Wenige Änderungen gute Wartbarkeit und Verträglichkeit Nachteil: gewisser (kleiner) Overhead - Wird ausgeglichen, da I/O channels besser beschäftigt gehalten werden können

Möglichkeit III: Low Latency Regelmäßige Ausführung des Schedulers, damit kritische Tasks möglichst schnell bedient werden - aber: zu häufige Ausführung stellt einen beachtlichen Overhead dar (Kompromiss)

Low Latency Patch Konzepte/Änderungen I Eingeführt von Ingo Molnar, jetzt gewartet durch Andrew Morton Einführung von expliziten Preemption Points in den Blöcken des Kernel Codes, die für lange Zeit ausgeführt werden (Iterationen über große Datenstrukturen) Problem: finden dieser Stellen (z.B. mit Tools möglich) und SICHERES Einfügen

Preemption Points Wenn Schleife eine gewisse Zeit gelaufen ist, Scheduler aufrufen if (current->need_resched) schedule(); Mögliche Taktik: Spinlock freigeben, Scheduler aufrufen und danach Spinlock wieder reservieren (lock breaking)

Zusammenfassung

Weitere Ansatzpunkte An real-time Anforderungen angepasster Schedulingalgorithmus - Pre-Scheduling - Flexiblere Policies Höhere Timer-Auflösung

Ausblick Preemption Patch hat gute Aussichten, in den offiziellen Kernel als Option integriert zu werden, vielleicht auch in Kombination mit dem Low Latency Patch Persönliche Meinung: Mit höheren Multimedia-Anforderungen steigt der Wunsch nach real-time auch für den Ottonormal-Benutzer Integration nötig