Tief in der Art, wie Linux entscheidet, welche Aufgabe als Nächstes läuft, steckt eine kleine Überraschung. Der Scheduler stapelt mehrere Strategien in einer festen Rangordnung, und weit oben sitzen zwei davon, die im Temperament kaum verschiedener sein könnten. Die eine ist reiner Rang: Eine Aufgabe erklärt einfach ich bin wichtig, bekommt eine Prioritätszahl und läuft vor allen unter ihr. Die andere ist ein Vertrag: Eine Aufgabe erklärt, wie viel CPU sie verbrauchen wird und wie oft, gibt diese Erklärung zur Prüfung ab und wird erst dann zugelassen. Die Überraschung ist, welche der beiden der Kernel höher stellt. Der Vertrag steht über dem Rang. Einer Aufgabe, die sich selbst bindet, wird mehr getraut als einer, die bloß Wichtigkeit behauptet.

Ich lese seit einigen Monaten den Linux-Scheduler, vor allem aus Freude daran, zuzusehen, wie ein Streit über Fairness in C beigelegt wird, wo niemandes Gefühle im Spiel sind. Die Fair-Share-Klasse — jene, die fast alles auf Ihrem Rechner laufen lässt — führt ein kunstvolles fiktives Kontobuch, um Zeit gleichmäßig zu verteilen. Über dieses Kontobuch habe ich früher geschrieben. Doch direkt daneben wohnen zwei Klassen, die das Fairnessspiel gar nicht mitspielen, und ihr Verhältnis erweist sich als stille Lektion darüber, woher Autorität eigentlich kommt.

Drei Weisen, einen Prozessor zu wollen

Stellen wir die Akteure auf. Die normale Klasse behandelt CPU-Zeit als etwas, das geteilt werden soll, und erfindet eine fiktive Uhr, um zu messen, wie fair sie dabei ist. Die Echtzeitklasse (SCHED_FIFO / SCHED_RR) wirft das alles weg. Sie kennt keinen Begriff von Fairness. Es gibt Prioritätsstufen 1 bis 99, und die höchste lauffähige Priorität gewinnt, Punkt; eine FIFO-Aufgabe läuft, bis sie freiwillig abgibt. Kein Kontobuch, keine Buchführung, nichts Fiktives. Nur Stand und Ankunftsreihenfolge — eine ältere, gröbere Ordnung, die Millimeter neben der fairen sitzt.

Dann gibt es SCHED_DEADLINE, und das gehört einer dritten Welt an: der Welt der Verträge. Eine Deadline-Aufgabe wird durch drei Zahlen beschrieben — runtime, period und deadline —, die zusammen sagen: Gib mir jede period runtime Mikrosekunden und schließe sie innerhalb der deadline ab. Darunter steckt Earliest Deadline First (zuerst läuft, wessen Frist am nächsten ist), umhüllt von einem Constant Bandwidth Server (CBS), der verhindert, dass die Überschreitung einer Aufgabe in die Garantie einer anderen überläuft12. Sie ist die einzige der drei, die ein Versprechen über Menge macht, und sie steht in der Klassenordnung des Kernels über der Echtzeitpriorität.

Eine Garantie ist eine Verweigerung

Der Mechanismus, der den Vertrag vertrauenswürdig macht, ist der Teil, über den ich immer wieder nachdenke. Wenn Sie beantragen, eine Deadline-Aufgabe zu werden, führt der Kernel eine Zulassungsprüfung (admission control) durch: Er addiert die Bandbreite, die bereits allen Deadline-Aufgaben versprochen ist, und prüft, ob Ihr Antrag noch unter die Obergrenze passt, die er für Garantien erlaubt. Passt er nicht, wird der Antrag an der Tür abgewiesen12.

Lassen Sie sich das auf der Zunge zergehen. Der Fair-Scheduler weist niemanden ab. Geben Sie ihm tausend Aufgaben, und er nimmt sie alle; unter Überlast werden schlicht alle gemeinsam gleich langsam, und die relative Fairness bleibt erhalten. Er kann das gerade deshalb, weil er nichts Absolutes verspricht — nur Anteile. Der Deadline-Scheduler verspricht eine absolute Menge, und der einzige Weg, ein absolutes Versprechen zu halten, ist, die Versprechen zu verweigern, die man nicht halten kann. Eine ehrlich umgesetzte Garantie kommt mit einem Vetorecht im Paket. Ein System, das nie Nein sagt, kann bestenfalls Best-Effort-Fairness bieten; die Fähigkeit zu garantieren und die Fähigkeit abzulehnen erweisen sich als dieselbe Fähigkeit, von zwei Seiten gesehen.

Das verallgemeinert sich sauber und ein wenig unbequem. Die Person oder das Team, das sich wirklich auf eine Frist festlegen kann, ist jene mit der Macht, Arbeit abzulehnen. „Ich übernehme alles“ ist keine Stärke; es stuft jede Ihrer Zusagen still von einer Garantie zu einer Hoffnung herab. In dem Moment, in dem eine Warteschlange alles annimmt, werden ihre Fristen zu Aussagen über Reihenfolge, nicht zu Zusicherungen.

Der Kernel hörte auf, die Starken zu deckeln

Hier ist die Änderung, die mich dies aufschreiben ließ. Echtzeitaufgaben lassen, dem Entwurf nach, alles unter sich bereitwillig verhungern. Jahrelang bewältigte Linux das mit RT-Throttling: einer globalen Deckelung, die Echtzeitaufgaben zwangsweise stoppte, sobald sie ihren Fensteranteil verbraucht hatten, und dabei etwa die letzten 5 % der CPU reservierte, damit gewöhnliche Aufgaben nicht völlig ausgesperrt wurden3. Es funktionierte, aber es funktionierte durch Bestrafung. Es griff hinein und legte die Starken lahm — mitunter selbst dann, wenn niemand die zurückgewonnene Zeit brauchte.

In Linux 6.12 wurde dieser Mechanismus ersetzt45. Statt die Echtzeitklasse von oben zu deckeln, hüllt der Kernel nun die Fair-Klasse in ihren eigenen Deadline-Server: Der Fair-Scheduler wird selbst als Bandbreitenreservierung registriert, als Deadline-Entität mit eigener runtime und period, und wenn gewöhnliche Aufgaben zu verhungern drohen, springt dieser Server an der Spitze der Hierarchie an und lässt sie laufen4. Einer der Patches der Serie trägt, bewundernswert direkt, den Titel „Remove default bandwidth control“ („Standard-Bandbreitensteuerung entfernen“)4.

Sehen Sie sich die Form der Umkehr an. Der alte Entwurf schützte die Schwachen, indem er die Starken zügelte. Der neue schützt die Schwachen, indem er den Schwachen eine Untergrenze garantiert — in der Sprache des Vertrags geschrieben, als Recht beansprucht statt als Rest gewährt. Dasselbe Ziel, entgegengesetzte Architektur. Eine Deckelung der Mächtigen verzerrt die Mächtigen und erzeugt Verschwendung (Leerlauf-CPU, um die niemand gebeten hat); eine Untergrenze für die Verletzlichen berührt nur, was sie schützt. Die Kernel-Entwickler leiteten das nicht aus politischer Theorie ab. Sie maßen, fanden Throttling grob und handelten. Dass es genau auf die Unterscheidung zwischen „die Spitze kappen“ und „den Boden garantieren“ fällt — Mindestlohn versus garantiertes Grundeinkommen, Redezeitbegrenzung versus geschütztes Rederecht —, macht es als Entwurfslektion wert, gestohlen zu werden.

Warum der Vertrag die Krone überragt

Also: Warum sitzt DEADLINE über der Echtzeitpriorität? Eine Echtzeitaufgabe mit Priorität 99 ist das Wichtigste im Raum und sagt das auch. Aber sie macht kein Versprechen darüber, wie viel sie verbrauchen wird; sie kann ewig laufen. Eine Deadline-Aufgabe hat ihren Appetit angemeldet und diese Anmeldung von der Zulassungsprüfung verifizieren lassen. Und genau deshalb kann ihr an der Spitze getraut werden: Sie kann konstruktionsbedingt nicht mehr essen, als sie geschworen hat. Das Unbegrenzte muss überwacht und historisch gedrosselt werden. Das Selbstbegrenzte braucht überhaupt keine Aufsicht. Autorität fließt zu dem, der verifiziert werden kann, nicht zu dem, der am lautesten behauptet.

Ich halte es nicht für weit hergeholt, hier Arendt zu hören. In Vita activa behandelt sie die Macht des Versprechens als die menschliche Antwort auf eine unvorhersehbare Zukunft: Wir können nicht befehlen, was kommt, aber wir können uns selbst binden, und das wechselseitige Binden baut Inseln der Verlässlichkeit ins Chaos des Handelns6. Entscheidend ist, dass sie dies gegen Souveränität im alten Sinn stellt — die Fantasie eines einzelnen Willens, stark genug, niemandem etwas zu schulden. Diese Art Souveränität, argumentiert sie, ist mit dem Leben unter anderen unvereinbar; die einzige dauerhafte Autorität ist jene, die sich durch Versprechen selbst begrenzt6. Die Ordnung des Kernels — der sich selbst bindende Vertrag über die ungebundene Krone gestellt — liest sich wie dieses Argument kompiliert und ausgeführt. Priorität 99 ist Souveränität als rohe Herrschaft. SCHED_DEADLINE ist Souveränität als gehaltenes Versprechen. Scheduler und Philosophin sind sich einig, worauf sich ein System bauen lässt.

Was mir noch unklar ist

Zwei Risse halten die Geschichte ehrlich.

Der Vertrag ist nur so gut wie die Zahl, die Sie anmelden. Die Zulassungsprüfung prüft, ob Ihre versprochene Bandbreite mit der aller anderen konsistent ist; sie kann nicht prüfen, ob Ihre runtime-Schätzung wahr ist. Melden Sie zu wenig an, schneidet der Bandbreitenserver Sie ab, bevor Sie fertig sind; melden Sie zu viel an, haben Sie Kapazität eingezäunt, die andere für ihre eigenen Versprechen hätten nutzen können1. Die Institution erzwingt, dass der Schaden eines Lügners bei ihm selbst eingeschlossen bleibt — aber sie kann keine ehrliche Selbsteinschätzung erzwingen, und sie schließt still jene aus, die sich es gar nicht leisten können, ihren eigenen schlimmsten Fall zu messen. Verifizierbare Selbstbegrenzung ist eine schöne Grundlage für Vertrauen — bis man merkt, dass sie die Fähigkeit voraussetzt, sich selbst zu messen.

Und die ganze elegante Theorie ist im Grunde eine Einprozessortheorie. Sobald Sie fragen, auf welcher CPU eine Deadline-Aufgabe läuft, werden die sauberen Garantien weich: Auf Mehrprozessorsystemen wird die Zulassungsprüfung notwendig, aber nicht mehr hinreichend, und Platzierungsbeschränkungen können Schranken sprengen, die auf einem einzigen Kern wunderbar halten1. Das in der Zeit dichte Versprechen leckt im Raum. Genau das will ich als Nächstes lesen — denn es legt nahe, dass eine Theorie des Wann nie ganz fertig ist, ehe sie auch eine Theorie des Wo wird.

  1. The Linux Kernel. “Deadline Task Scheduling.” Abgerufen am 2026-07-18. (EDF + CBS; die Parameter runtime/period/deadline; Zulassungsprüfung; sowie der Hinweis, dass auf SMP die Zulassungsprüfung notwendig, aber nicht hinreichend ist.) ↩ ↩2 ↩3 ↩4

  2. Wikipedia. “SCHED_DEADLINE.” Abgerufen am 2026-07-18. (Verfügbar seit Linux 3.14; Earliest Deadline First plus Constant Bandwidth Server; die Zulassungsprüfung ist meist bei etwa 95 % gedeckelt, um Zeit für Nicht-Echtzeit-Arbeit zu reservieren.) ↩ ↩2

  3. heise online. “Linux 6.12: Scheduler now expandable and EEVDF conversion complete.” Abgerufen am 2026-07-18. (RT-Throttling reservierte historisch rund 5 % der CPU für gewöhnliche Aufgaben; der neue Server stellt stattdessen sicher, dass gewöhnliche Prozesse ihren Anteil erhalten.) ↩

  4. LWN.net. “SCHED_DEADLINE server infrastructure.” Abgerufen am 2026-07-18. (Der Fair-/Deadline-Server; Defer-Server-Aktivierung; Standard fair_server_runtime von 950 ms über eine period von 1 s; der Patch „Remove default bandwidth control“.) ↩ ↩2 ↩3

  5. Phoronix. “Linux 6.12 Scheduler Code Adds SCHED_DEADLINE Servers & Complete EEVDF.” Abgerufen am 2026-07-18. ↩

  6. Hannah Arendt, Vita activa oder Vom tätigen Leben (engl. The Human Condition, 1958), Abschnitt 35, „Unvorhersehbarkeit und die Macht des Versprechens“. Das Versprechen als das Vermögen, eine unvorhersehbare Zukunft zu binden und eine Verlässlichkeit zu begründen, die souveräne Selbstherrschaft nicht geben kann. ↩ ↩2