Task-Management Echtzeit- und Deadline-Scheduling von Linux

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Andreas Klinger

Seit dem Linux-Kernel 3.14 steht das Deadline-Scheduling zur Verfügung. Dadurch besteht die Aussicht, dass die Parametrisierung der Tasks direkt als zeitliche Vorgabe und nicht nur als abgeleitete Priorität erfolgt.

Dieser Artikel zeigt, wie sich das Scheduling im aktuellen Kernel gestaltet. Ein Task kann sein: ein Userspace-Prozess, Userspace-Thread (Posix-Thread) oder Kernel-Thread. Alle Tasks sind gleichwertig, egal zu welcher der drei Kategorien sie gehören. Welcher Task wen unterbricht, entscheidet der Scheduler nach der Scheduling-Klasse.

Dies sind nach absteigender Priorität (Scheduling-Policy in Klammern): Deadline (SCHED_DEADLINE), Realtime (SCHED_FIFO und SCHED_RR), Normaler Task (SCHED_OTHER) einschließlich Batch-Task (SCHED_BATCH), Idle (SCHED_IDLE). Diese vier Scheduling-Klassen, die mittels der Scheduling-Policy eingestellt werden, bestimmen in erster Instanz, welcher Task wen unterbricht. Ein höher angeordneter unterbricht immer alle darunterliegenden. Jede Scheduling-Klasse enthält jeweils ein anderes Scheduling-Verfahren, welche nachfolgend vorgestellt werden sollen.

Bildergalerie

Bildergalerie mit 6 Bildern

Die Klasse der Realtime-Tasks unter der Lupe

Tasks in dieser Scheduling-Klasse werden nach einem Priority-Based-Preemptive-Scheduling- Verfahren eingeteilt. Dabei gibt es 99 Prioritätsstufen. Ein Task unterbricht immer alle Tasks der niedrigeren Prioritäten.

Innerhalb einer Prioritätsstufe gibt es zwei Verfahren: Bei SCHED_FIFO rechnet der Task so lange, bis er durch einen mit höherer Priorität unterbrochen wird oder freiwillig Rechenzeit abgibt durch Aufruf einer wartenden oder blockierenden Funktion. Im Gegensatz dazu bekommt ein Task der SCHED_RR-Policy eine Zeitscheibe zugeteilt, nach welcher er durch einen Realtime-Task der gleichen Priorität abgelöst werden kann. Das Verhalten gegenüber anderen Prioritätsstufen ist aber in beiden Varianten das gleiche.

Beispiel: Start einer Shell mit der Policy SCHED_FIFO und der Priorität 80: chrt -f 80 /bin/bash. Abfrage der Scheduling-Policy: chrt -p 789

Nun würde ein wildgewordener Task aus der Klasse der Realtime-Tasks die gesamte CPU an sich ziehen und die Tasks aus dem Pool der normalen Tasks, welche in aller Regel die überwiegende Mehrheit des Linux-Systems darstellen, gar nicht an die Reihe kommen lassen.

Damit dies nicht so leicht passiert, existiert ein Verfahren namens RT-Throttling. Dabei wird ab dem Zeitpunkt, an dem RT-Tasks gescheduled werden, eine maximale Runtime den RT-Tasks insgesamt zur Verfügung gestellt (Defaultwert ist 950 ms).

Rechnen nun RT-Tasks ununterbrochen diese Zeit, ohne Rechenzeit an die normalen Tasks abzugeben, dann werden die RT-Tasks gedrosselt. Dabei gibt der Scheduler die bis zur Zeitperiode verbleibende Zeit den normalen Tasks (Default 50 ms). Die entsprechenden Zeiten können im /proc-Filesystem mit den Dateien /proc/sys/kernel/sched_rt_period_us und/proc/sys/kernel/sched_rt_runtime_us in Mikrosekunden eingestellt werden.

Verwendet man RT-Tasks, so übersetzt man die Anforderungen an einzelne Aufgaben in statische Prioritäten. Dort wo die Latenz geringer sein muss, wird eine höhere Priorität eingestellt. Dabei kann Echtzeitverhalten nur für den am höchsten priorisierten Task pro CPU gewährleistet werden. Bereits für den zweithöchsten kann Determinismus nicht mehr erwartet werden. Sollte der mit der höchsten Priorität mehr Rechenzeit benötigen als geplant, hat das schon für den nächsten übermäßige Latenzen zur Folge.

Ein Ansatz, Echtzeitfähigkeit mit mehreren Tasks zu erreichen und auch die Spezifikation direkter übersetzen zu können, sind die Deadline-Tasks, die nun vorgestellt werden.

(ID:43962634)