Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Scheduler: Übungsaufgabe

Aufgaben

Ziel: Du lernst den grundlegenden Umgang mit Schedulern unter Linux/Unix.

Übung 1: Fair Scheduling (CFS-Grundidee)

Ziel: Verstehen, dass der Completely Fair Scheduler CPU‑Zeit möglichst gleich verteilt.

Starte mehrere CPU-lastige Prozesse und beobachte die CPU Verteilung. Führe hierzu in der Shell folgende drei Befehle aus:

taskset -c 0 yes > /dev/null &
taskset -c 0 yes > /dev/null &
taskset -c 0 yes > /dev/null &

Beobachte die Prozesse mit 

top

und mit 

htop

Hinweis: yes > /dev/null & ist eine klassischer Scheduler‑Testbefehl. Er erzeugt maximale CPU‑Last, ohne Ausgaben zu erzeugen. yes schreibt endlos eine Zeichenkette auf die Standardausgabe, rechnet nichts, verbraucht aber so viel CPU wie möglich. > /dev/null leitet die Standardausgabe nach /dev/null um. /dev/null ist ein spezielles Device (Gerät), das alle Daten, die dort hineingeschrieben werden, sofort und endültig verschwinden. In unserem Fall wird dadurch keine I/O verbraucht und Du generierst reine CPU-Last. Das Ampersand-Symbol & startet den Prozess im Hintergrund. Sieh hierzu auch die Übungsaufgauben zu Prozessen. Der Teil taskset -c 0 führt dazu, dass der Prozess auf CPU/Core 0 ausgeüfhrt wird. SOmit muss der Scheduler die CPU-Leiistung aufteilen.

Du wirst sehen, dass jede CPU ungefähr 33% CPU Leistung erhält. Stehen mehreer CPUs zur Verfügung sollte jeder Prozess 100% CPU-Leistung erhalten - achte in diesem Fall auf die Zeit, die die Prozesse verbraucht haben. Die Werte sollten nahe beieinander liegen. Führe die Übung später nochmal aus - lasse dann aber den Teil taskset -c 0 weg.

Beende nun alle Prozesse mit dem Befehl

killall yes

Übung 2: Prioritäten mit nice

Ziel: Einfluss von Prioritäten auf den Scheduler verstehen.

Starte drei Prozesse mit unterschiedlichen nice-Werten:

Dur wirst nun sehen, dass die Prozesse unterschiedlich viel Zeit erhalten:

  • nice 0 → meiste CPU

  • nice 10 → weniger CPU

  • nice 19 → deutlich weniger CPU

Beende nun wieder alle Prozesse mit killall yes .

Hinweis: Unter Linux gilt:

  • Jeder Benutzer darf seine Prozesse „netter“ machen → also den nice‑Wert erhöhen (z. B. von 0 auf 10 oder 19)

  • Nur root darf Prozesse „unhöflicher“ machen → also den nice‑Wert senken (z. B. von 0 auf −5)

Niedriger nice‑Wert bedeutet:

  • geringere vruntime

  • Prozess bekommt mehr CPU‑Zeit

  • andere Prozesse bekommen weniger

Das betrifft alle anderen Benutzer und Prozesse.

Mit dem Befehl

wäre es im Prinzip möglich alle anderen Prozesse verhungern zu lassen.

Übung 3: Dynamische Änderung von Prioritäten

Ziel: Lernen, dass dass Scheduler-Verhalten zur Laufzeit angepasst werden können.

Starte wie in Übung 2 drei Prozesse mit unterschiedlichen nice-Werten (alle auf CPU/Core 0).

Beobachte den CPU-Verbrauch der drei Prozesse mittels htop.

Finde nun die Prozess-ID (pid) des Prozesses mit dem nice-Wert 0. Ändere nun den nice-Wert wie folgt:

Anstelle <pid> gib die ermittelte Prozess-ID an, z.B. renice 15 -p 1432 .

Beobachte nochmals den CPU-Verbrauch der Prozesse mittels htop. Du solltest nun beobachten können, dass der CPU-Verbrauch des Prozesses unter den mit dem nice-Wert 10 fällt.

Übung 4: CPU-bound vs. I/O-bound

Ziel: Verstehen warum interaktive Programme ansprechbar bleiben

Öffne drei Terminals (Shells) bzw. unter Windows WSL drei Fenster mit der gleichen Linux-Instanz.

In Terminal 1 starte

In Terminal 2 starte

In Terminal 3 starte

Hinweis:

watch -n 1 date macht immer wieder:

  1. sleep (Timer blockiert)

  2. date ausführen (kurz CPU)

  3. Ausgabe ins Terminal (I/O)

  4. wieder schlafen

watch -n 1 date ist I/O‑intensiv, da es nur kurze CPU‑Bursts ausführt und den Großteil der Zeit auf Timer‑ und Ein-/Ausgabe‑Operationen wartet und somit blockiert. yes hingegen ist ein CPU‑lastiger Prozess, der permanent rechnet und nie blockiert.

Hinweis: An diesem Beispiel kannst Du die Funktionsweise von Preemtion erkennen. date aktualisiert sich flüssig, obwohl yes fast die gesamte CPU blockiert. yes wird jedoch ständig unterbrochen um date auszuführen.

Übung 5: Echtzeitschedulung und Round Robin

Starte nun

Hinweis: Der Befehl startet einen Echtzeit‑Prozess mit Round‑Robin‑Scheduling, Priorität 50, der endlos CPU verbraucht und im Hintergrund läuft.

Mit chrt (change real‑time scheduling) wird die Scheduler‑Klasse und die Echtzeit‑Priorität eines Prozesses gesetzt. -r steht für Round-Robund (SCHED_RR) - diese Prozesse laufen for normalewn CFS-Prozessen. Mit 50 wird die Echtzeit-Priorität angegeben (1-99) - je grpßer die Zahl ist, desto höher ist die Priorität.

Als Faustrtegel gilt: Niedrige Real-Time-Prozesse verlieren gegenüber hohen Real-TimeProzessen, normales Scheduling verliert immer gegenüber Real-Time Prozessen,

Übung 6: Hart am Limit

Führe diese Übung nur durch, wenn Du die vorherigen Übungen durchgearbeitet hast und dich auf der Konsole sicher fühlst.

Ziel: Dein System für kurze nahezu unbrauchbar machen.

Start ezunächst zwei Shelles (oder unter Widows WSL zwei linux-Fenster). Führe nun für jede CPU folgenden Befehl aus:

Ersetze dabei bei jedem Aufruf 0 durch die nächste Ziffer (1, 2, 3 etc.) - abhängig davon wieviele CPUs in deinem Rechner verbaut sind. Hierdurch wird ein hoch-priorisierter Real-Time-Prozess auf der CPU gestartet.

Nach dem Start auf der vorletzten bzw. letzten CPU sollte das Terminal beginnen sehr verzögert zu reagieren. Grund hierfür ist, dass die Real-Time-Prozesse nun (fast) alle CPUs blockiere und alle anderen Prozesse im Scheduling verlieren.

Beende nun alle Prozesse mit

Dein System sollte schlagartig wieder reagieren.

PreviousFortgeschrittene SchedulerNextFortgeschrittene Speicherverwaltung

Last updated