Linux 7.2: Neuer Cache-Scheduler für AMD und Intel

Linux bekommt mit Cache Aware Scheduling eine unscheinbare, aber wichtige Änderung im Kernel: Der Scheduler soll Threads näher an dem Cache halten, den sie wirklich nutzen. Für Desktop-Spieler ist das kein magischer FPS-Schalter, für Server, Workstations und große AMD- oder Intel-CPUs aber ein ziemlich praktisches Stück Klempnerarbeit.

Der Linux-Kernel ist selten dann spannend, wenn er laut wirkt. Spannend wird er meistens dort, wo eine Änderung tief im Maschinenraum ansetzt und erst später in Benchmarks, Datenbanken oder auf stark ausgelasteten Servern sichtbar wird. Genau in diese Kategorie fällt das Cache Aware Scheduling, das nach aktuellem Stand in Linux 7.2 landet. Die Funktion wurde laut Phoronix-Bericht zur Scheduler-Merge-Runde in den Scheduler-Zweig aufgenommen und ist über die Kernel-Option CONFIG_SCHED_CACHE erreichbar.

Der Name klingt nach Feintuning für Menschen, die auch Kernel-Config-Menüs zum Frühstück lesen. Tatsächlich geht es um ein alltägliches Problem moderner Prozessoren: Viele Kerne bedeuten nicht automatisch, dass jeder Thread an jeder Stelle gleich gut aufgehoben ist. Wenn eine CPU mehrere Last-Level-Caches besitzt, kann es teuer werden, zusammengehörige Aufgaben quer über diese Cache-Domänen zu verteilen. Der neue Ansatz versucht deshalb, Aufgaben mit gemeinsamen Daten näher zusammenzuhalten.

Was Cache Aware Scheduling im Kernel verändert

Ein Scheduler entscheidet, welcher Prozess oder Thread auf welchem CPU-Kern läuft. Das klingt simpel, ist auf aktuellen Prozessoren aber ein permanenter Kompromiss. Der Kernel muss Last verteilen, Latenzen niedrig halten, Energieverbrauch berücksichtigen und gleichzeitig vermeiden, dass Daten unnötig zwischen Caches hin und her wandern. Cache Aware Scheduling ergänzt diese Entscheidung um eine weitere Frage: Teilen sich Aufgaben wahrscheinlich Daten, und sollten sie deshalb auf Kernen laufen, die denselben Last-Level-Cache nutzen?

Der technische Kern ist nicht, jeden Thread stur an einen festen Kern zu kleben. Das wäre auf Dauer sogar schlecht, weil Lastspitzen dann nicht mehr sauber verteilt würden. Stattdessen wird die Lastverteilung cache-bewusster. Die Patch-Serie von Tim Chen auf LWN beschreibt das Ziel recht nüchtern: Threads, die Daten teilen, sollen möglichst innerhalb derselben LLC-Domain laufen, um Cache-Bouncing und Cache-Misses zu reduzieren. Übersetzt: Weniger unnötige Datenreisen, weniger Wartezeit, mehr Arbeit pro Takt. Für Admins ist das dieselbe nüchterne Kategorie wie ein sauber geplanter Linux-Kernel-Patch: unspektakulär, aber im Betrieb entscheidend.

Das ist kein neues Zauberwort, sondern eine logische Antwort auf die Hardware der letzten Jahre. AMD setzt bei vielen Ryzen-Threadripper- und Epyc-Prozessoren auf Chiplet-Designs mit mehreren CCDs und getrennten L3-Caches. Intel hat mit Xeon-Generationen ebenfalls Plattformen, bei denen große Kernzahlen und komplexere Cache-Topologien zur Normalität gehören. Der Linux-Scheduler muss diese Topologien sauberer ausnutzen. Sonst verhält sich ein Vielkernsystem gelegentlich wie ein Lagerhaus, in dem alle ständig durch die falsche Tür laufen.

Warum gerade AMD Epyc, Threadripper und Xeon profitieren

Der größte Nutzen entsteht dort, wo mehrere Last-Level-Caches im Spiel sind und Workloads viele Threads parallel bewegen. Genau deshalb tauchen in den bisherigen Berichten vor allem Plattformen wie AMD Epyc 9005, Ryzen Threadripper 9980X und Intel Xeon 6 auf. Auf solchen Systemen ist die Frage, wo ein Thread läuft, nicht akademisch. Sie entscheidet darüber, ob Daten im nahen Cache liegen oder über eine langsamere Strecke geholt werden müssen.

Für Betreiber von Linux-Servern ist das besonders interessant. Datenbanken, In-Memory-Stores, Netzwerkdienste und Build-Systeme erzeugen oft Lastmuster, bei denen viele Threads mit teilweise gemeinsamen Datenstrukturen arbeiten. Wenn der Kernel diese Threads klüger auf Cache-Domänen verteilt, kann das messbare Vorteile bringen. Phoronix nennt in den bisherigen Tests unter anderem PostgreSQL, Valkey und Netzwerk-Performance als Bereiche mit sichtbaren Gewinnen. Das ist kein Marketing-Benchmark auf Hochglanzpapier, sondern ziemlich nah an echter Admin-Arbeit.

Gleichzeitig bleibt der Effekt workload-abhängig. Ein schlecht angebundener Datenträger, zu wenig RAM oder eine limitierende Anwendung verschwinden nicht, nur weil der Scheduler ein neues Werkzeug bekommt. Cache Aware Scheduling verbessert eine bestimmte Klasse von Engpässen. Es ersetzt keine saubere Datenbankkonfiguration, keine NUMA-Planung und kein Monitoring. Wer Server betreibt, sollte es also als zusätzlichen Baustein sehen, nicht als Freifahrtschein.

Für Unternehmen, die Linux als Plattform für produktive Dienste einsetzen, passt die Änderung in ein größeres Bild: Der Kernel wird nicht nur sicherer oder hardwarekompatibler, sondern versucht auch, vorhandene Hardware intelligenter zu nutzen. Das gilt besonders für Systeme, die ohnehin teuer sind. Wenn ein Epyc- oder Xeon-Server viele Kerne und viel Cache mitbringt, sollte der Scheduler diese Architektur nicht wie eine flache Kernliste behandeln. Dazu gehört auch, dass Teams Sicherheits- und Performance-Themen nicht getrennt denken; ein aktueller Blick auf Linux-Schwachstellen zeigt, wie schnell Kernel-Details im Alltag relevant werden.

Was Desktop-Nutzer und Spieler realistisch erwarten sollten

Für klassische Desktop-Systeme fällt die Einordnung nüchterner aus. Wer einen Linux-PC mit einem normalen Ryzen, Core-Prozessor oder auch einem X3D-Modell nutzt, sollte keine Wunder erwarten. Viele Desktop-Anwendungen laufen nicht dauerhaft mit Dutzenden Threads, die über mehrere Cache-Domänen verteilt werden. Spiele wiederum reagieren stark auf GPU-Limits, Engine-Design, Treiber, Shader-Compilation und einzelne Hauptthreads. Ein besserer CPU-Scheduler kann helfen, ist aber selten der alleinige Hebel.

Das heißt nicht, dass Desktop-Nutzer leer ausgehen. Ein System mit vielen Hintergrunddiensten, Containern, Browser-Tabs, Compiler-Jobs und gleichzeitig laufenden Anwendungen kann von smarter Lastverteilung profitieren. Nur wird der Gewinn dort eher als stabileres Verhalten unter Last auffallen als als spektakulärer Balken in einem Gaming-Test. Wer Linux produktiv auf einer großen Workstation nutzt, ist näher an der Zielgruppe als jemand, der nur ein Spiel startet und auf mehr Bilder pro Sekunde hofft.

Gerade bei AMDs Chiplet-Designs ist die Versuchung groß, aus jeder Scheduler-Änderung eine Gaming-Schlagzeile zu machen. Das wäre hier zu billig. Cache Aware Scheduling adressiert nicht primär die Frage, welcher Kern am höchsten boostet oder welcher CCD den 3D-V-Cache trägt. Es geht um Datenlokalität über Last-Level-Caches hinweg. Das kann in bestimmten Szenarien sehr wertvoll sein, muss aber nicht automatisch den Frametime-Verlauf jedes Spiels glätten.

Der wichtige Unterschied zwischen Kernel-Merge und Nutzer-Alltag

Linux 7.2 ist derzeit noch nicht der stabile Alltagskernel auf typischen Distributionen. Auf kernel.org ist aktuell Linux 7.1 als Mainline-Release gelistet; Linux 7.2 befindet sich im Entwicklungszyklus. Das ist wichtig, weil ein Merge in den Kernel nicht bedeutet, dass die Funktion morgen auf jedem Ubuntu-, Fedora-, Debian- oder Arch-System produktiv läuft. Distributionen müssen den Kernel übernehmen, konfigurieren, testen und ausrollen.

Zusätzlich hängt die praktische Verfügbarkeit von der Kernel-Konfiguration ab. Wenn CONFIG_SCHED_CACHE nicht aktiviert ist, bringt Ihnen der theoretische Codepfad wenig. Bei Rolling-Release-Distributionen kann die Funktion vergleichsweise schnell auftauchen. Enterprise-Distributionen werden deutlich konservativer vorgehen, Backports prüfen oder erst spätere Kernelstände übernehmen. Das ist langweilig, aber gesund. Kernel-Scheduling ist kein Bereich, in dem man produktive Systeme aus Abenteuerlust umstellt.

Admins sollten deshalb vor allem drei Dinge beobachten: Erstens, ob die eigene Distribution Linux 7.2 mit aktiviertem Cache Aware Scheduling ausliefert. Zweitens, ob relevante Workloads in unabhängigen Benchmarks profitieren. Drittens, ob eigene Messungen auf echter Hardware den Effekt bestätigen. Die dritte Frage ist die wichtigste. Ein PostgreSQL-Server, ein CI-Runner und ein Virtualisierungshost können völlig unterschiedlich reagieren.

Für Testsysteme ist die Änderung trotzdem reizvoll. Wer Kernel selbst baut, kann gezielt mit CONFIG_SCHED_CACHE experimentieren und Workloads vorher und nachher vergleichen. Sinnvoll sind dabei reproduzierbare Tests: gleiche Datenbasis, gleiche Lastprofile, gleiche Kernel-Parameter, mehrere Durchläufe. Ein einzelner schnellerer Benchmarklauf ist noch keine Erkenntnis. Das Terminal freut sich über Statistik, nicht über Wunschdenken.

Warum diese Scheduler-Arbeit mehr ist als ein Spezialfall

Cache Aware Scheduling zeigt, wohin sich Linux entwickeln muss: Hardware wird heterogener, größer und intern komplizierter. Der Kernel kann nicht mehr nur fragen, ob ein Kern frei ist. Er muss verstehen, welche Kerne sich Cache, Energiegrenzen, Topologien und manchmal sogar unterschiedliche Fähigkeiten teilen. Das gilt nicht nur für Serverprozessoren, sondern zunehmend auch für Desktop- und Mobilplattformen.

Man sieht diesen Trend bereits an anderen Scheduler-Themen: asymmetrische CPU-Kapazitäten, SMT-Bewusstsein, NUMA-Nähe, Energieprofile und Spezialfälle rund um große und kleine Kerne. Cache Aware Scheduling fügt sich hier ein. Es ist kein isolierter Patch für Benchmark-Fans, sondern Teil der langfristigen Arbeit, Linux besser an moderne Prozessoren anzupassen. Die Änderung ist deshalb auch dann relevant, wenn sie auf Ihrem aktuellen Notebook kaum messbar ist.

Aus Sicht von Unternehmen hat das einen angenehmen Nebeneffekt. Performance-Verbesserungen im Kernel landen oft unterhalb der Anwendungsebene. Niemand muss PostgreSQL neu schreiben, nur weil der Scheduler bessere Entscheidungen trifft. Niemand muss einen Webdienst umbauen, damit Threads weniger Cache-Streit verursachen. Natürlich ersetzt das keine Optimierung in der Anwendung selbst. Aber es verschiebt die Basislinie nach oben. Und genau solche Basislinien-Verbesserungen machen Linux im Rechenzentrum stark. Bei Enterprise-Distributionen zeigt sich diese Logik besonders deutlich, weil Themen wie RHEL, Hybrid Cloud und Kernel-Basis immer zusammen bewertet werden.

Was Sie jetzt prüfen können

Wenn Sie Linux privat nutzen, reicht zunächst Gelassenheit. Warten Sie ab, bis Ihre Distribution Linux 7.2 regulär anbietet, und prüfen Sie dann, ob sich unter Ihrer typischen Last etwas verändert. Wer eine Workstation mit vielen Kernen betreibt, kann zusätzlich Benchmarks mit Compiler-Jobs, Containern, virtuellen Maschinen oder Datenbanktests laufen lassen. Aussagekräftiger als ein synthetischer Einzelwert ist dabei immer ein realer Ablauf aus Ihrem Alltag.

Wenn Sie Linux-Server betreiben, lohnt sich eine etwas strukturiertere Vorbereitung. Dokumentieren Sie die aktuelle Kernel-Version, prüfen Sie die CPU-Topologie und sammeln Sie Basismessungen für die wichtigsten Dienste. Bei Datenbanken können Latenzen, Durchsatz, CPU-Auslastung und Cache-Miss-Metriken interessant sein. Bei Netzwerkdiensten zählen Paketdurchsatz, Latenzspitzen und CPU-Verteilung. Danach lässt sich ein Kernel-Upgrade sauberer bewerten.

Praktisch heißt das: Notieren Sie vor dem Test, welche Kernel-Konfiguration wirklich läuft, welche CPU-Topologie das System meldet und welche Dienste parallel aktiv sind. Werkzeuge wie lscpu, numactl --hardware, perf stat oder die Metriken Ihrer Monitoring-Plattform liefern dafür genug Anhaltspunkte. Wichtig ist nicht, jede Cache-Statistik perfekt zu deuten. Wichtig ist, dass Sie vor und nach dem Upgrade dieselben Messpunkte vergleichen. Sonst wird aus Kernel-Tuning nur Kaffeesatzlesen mit Root-Rechten.

Wichtig ist auch: Testen Sie nicht nur den Durchschnitt. Scheduler-Änderungen können in bestimmten Lastspitzen helfen oder schaden, während der Mittelwert unauffällig bleibt. Gerade produktive Server interessieren sich selten für schöne Durchschnittswerte. Entscheidend ist, ob die 95. oder 99. Perzentile stabiler wird, ob Warteschlangen kürzer bleiben und ob die CPU unter Last berechenbarer arbeitet.

Was am Ende für Linux-Systeme zählt

Cache Aware Scheduling in Linux 7.2 ist keine Funktion, die man im Desktop-Menü anklickt. Sie ist auch keine Garantie für mehr Spieleleistung. Trotzdem ist sie wichtig. Moderne Prozessoren werden nicht einfacher, und der Kernel muss die interne Architektur besser verstehen, wenn große Vielkernsysteme effizient laufen sollen.

Für AMD Epyc, Ryzen Threadripper und Intel Xeon ist die Änderung besonders spannend, weil dort mehrere Cache-Domänen und viele Threads im Alltag zusammentreffen. Für normale Desktop-Nutzer bleibt der Effekt vermutlich kleiner, aber nicht bedeutungslos. Der eigentliche Wert liegt darin, dass Linux eine weitere Hardware-Eigenheit nicht länger nur hinnimmt, sondern aktiv in Scheduling-Entscheidungen einbezieht. Genau so sieht unspektakulärer Fortschritt aus. Kein Feuerwerk. Aber weniger unnötige Wege durch den Cache. Und manchmal ist genau das der Unterschied zwischen „läuft“ und „läuft sauber“.