Ein Angebot von

Task-Management

Realtime- und Deadline-Scheduling von Linux

| Autor / Redakteur: Andreas Klinger * / David Franz

Das Linux-Maskottchen Tux: Das Taskmanagement unter Linux wurde durch Einführung des Deadline-Scheduling deutlich vereinfacht.
Das Linux-Maskottchen Tux: Das Taskmanagement unter Linux wurde durch Einführung des Deadline-Scheduling deutlich vereinfacht. (Bild: Larry Ewing, Simon Budig)

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:

- Userspace-Prozess,

- Userspace-Thread (Posix-Thread),

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

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.

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Ausklappen
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Ausklappen
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 43962634 / Open Source)