Verbesserung der Reaktivität des Linux-Kernels Steffen Mazanek

1. Verbesserung der Reaktivität des Linux-KernelsSteffen Mazanek

2. 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

3. 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

4. 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)

5. 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

6. 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

7. 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

9. 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

10. 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

11. 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

13. Kernel Preemption PatchKonzepte/Ä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)

14. Kernel Preemption PatchKonzepte/Ä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

15. 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

16. 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)

17. Low Latency PatchKonzepte/Ä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

18. 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)

20. Zusammenfassung

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

22. 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