Linux-Kernel 7.2: Was bringt das für VPS?

Was ist neu im Linux-Kernel 7.2

Linux-Kernel 7.2 wurde am 16. August 2026 veröffentlicht. Die wichtigste Änderung ist cache-aware Scheduling, das hinter der neuen Option CONFIG_SCHED_CACHE implementiert ist. Der Scheduler versucht nun, die Threads eines Prozesses auf CPUs auszuführen, die denselben Last-Level-Cache (LLC) verwenden. Keine andere Änderung in diesem Release beeinflusst, wie Ihre Workload auf CPUs verteilt wird.

Der Rest von 7.2 in einer Zeile: eine Überarbeitung des schnellen ext4-Commit-Pfads, Verbesserungen an MGLRU (dem Speicher-Reclaim-Code für Least Recently Used über mehrere Generationen), ein neues dm-inlinecrypt-Device-Mapper-Ziel für die Inline-Verschlüsselung von Blockgeräten und die Entfernung des letzten strncpy()-Aufrufs aus dem Kernel-Quellcode.

Eine Tatsache entscheidet darüber, ob die wichtigste Funktion für Sie überhaupt etwas bewirken kann. Deshalb steht sie an erster Stelle. Cache-aware Load-Balancing wird nur aktiviert, wenn ein NUMA-Knoten (Non-Uniform Memory Access) mehr als einen LLC enthält. Bei einem VPS-Gast wird diese Topologie normalerweise nicht angezeigt. Daher ist der Code bei den meisten Gästen zwar einkompiliert, wird aber nie aktiviert. Mit zwei Befehlen können Sie das prüfen. Die Anleitung dazu finden Sie weiter unten unter „Sieht ein VPS-Gast davon etwas?“.

Jede technische Aussage auf dieser Seite stammt aus dem Changelog von 7.2 und aus der Patch-Serie zum cache-aware Scheduling, die am 18. August 2026 geprüft wurde. Die Quellen sind weiter unten aufgeführt. So können Sie sie mit dem Verhalten Ihres eigenen Kernels abgleichen.

Warum der Scheduler Caches berücksichtigen musste

Ein moderner Server-Socket verfügt nicht über einen einzigen Last-Level-Cache. Ein AMD-EPYC-Package besteht aus mehreren Core Complexes, und jeder Complex hat einen eigenen L3-Cache. Auch aktuelle Intel-Xeon-Prozessoren teilen einen Socket in mehrere Cache-Domänen auf. Daher kann ein einzelner NUMA-Knoten vier, acht oder mehr separate LLCs enthalten. Zwei Threads desselben Programms können dadurch in unterschiedlichen LLCs landen.

Diese Platzierung kostet Zeit. Wenn zwei Threads eine Seite aus unterschiedlichen LLCs gemeinsam verwenden, hält jeder Cache eine eigene Kopie der Cacheline. Ein Schreibzugriff auf einer Seite invalidiert die Kopie auf der anderen Seite. Der nächste Lesezugriff muss daher die Interconnect-Verbindung überqueren oder auf den Hauptspeicher zugreifen. Dieses Verhalten wird als Cache-Bouncing bezeichnet. Es zeigt sich in wartenden CPU-Zyklen, nicht in ungenutzter CPU-Zeit. Deshalb wird es leicht übersehen, wenn Sie die Load Average beobachten.

Vor 7.2 platzierte der Load Balancer Tasks anhand von Load, Auslastung und verfügbaren CPUs. Ihm fehlte die Information, dass „diese beiden Tasks denselben Speicher lesen“. 7.2 ergänzt diese Information mithilfe einer Näherung, deren Berechnung nichts kostet: Die Threads eines Prozesses verwenden denselben Adressraum und teilen daher wahrscheinlich Daten.

Wie der Kernel eine bevorzugte LLC auswählt

Die Zuordnung ist am Prozess verankert, in mm_struct, der Kernel-Struktur, die einen Adressraum repräsentiert. Der Kernel erfasst regelmäßig, auf welchen CPUs die Threads dieses Prozesses laufen, und zählt für jede LLC, wie viel des Prozesses sich dort befindet. Die LLC mit dem größten Anteil wird zur bevorzugten LLC des gesamten Prozesses. Spätere Entscheidungen verwenden genau diesen einzelnen Wert.

Anschließend verwenden zwei Pfade diesen Wert. Beim Aufwecken bevorzugt der Scheduler CPUs in der bevorzugten LLC des Prozesses, statt eine beliebige freie CPU im Node auszuwählen. Beim Load-Balancing zwischen Scheduler-Gruppen werden bevorzugt Tasks verschoben, die bereits die Ziel-LLC bevorzugen. Außerdem wird vermieden, einen Task von der von ihm bevorzugten LLC wegzubewegen.

Die Begrenzungen sind ebenso wichtig wie die Funktion selbst. Wenn alle Threads eines ausgelasteten Prozesses in einer Cache-Domain gebündelt werden, kann diese Domain überlastet sein, während der restliche Socket untätig bleibt. Die Tuning-Parameter befinden sich im debugfs, dem Debug-Dateisystem des Kernels, unter /sys/kernel/debug/sched/:

• llc_aggr_tolerance, ein Wert von 0 bis 100, legt fest, wie stark der Kernel aggregiert. 0 deaktiviert Cache-Aware Scheduling zur Laufzeit. 1 ist die vorsichtige Einstellung: Ein Prozess, dessen RSS (Resident Set Size, also sein residenter Speicher) größer als die LLC ist oder der mehr Threads ausführt, als die LLC Kerne hat, bleibt unverändert. 100 aggregiert unabhängig von der Größe und der Thread-Anzahl.
• llc_overload_pct, standardmäßig 50, legt die durchschnittliche Auslastung fest, ab der die bevorzugte LLC als ausgelastet gilt.
• llc_imb_pct, standardmäßig 20, begrenzt das Ungleichgewicht, das eine aggregierende Migration verursachen darf, sobald die bevorzugte LLC diesen Überlastungspunkt überschritten hat.
• llc_epoch_period, standardmäßig 10 ms, legt fest, wie oft die Belegung erfasst wird.
• llc_epoch_affinity_timeout, standardmäßig 50 ms, legt fest, wie lange ein inaktiver Prozess seine Präferenz behält, bevor der Kernel sie verwirft.

Lesen Sie Ihre aktuellen Werte, bevor Sie sie ändern. Eine Distribution kann andere Standardwerte ausliefern: sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance.

Welche Workloads plausibel profitieren und welche nicht

Die folgenden Zahlen wurden zusammen mit der Patch-Serie veröffentlicht. Sie wurden auf Hardware der Serverklasse gemessen, teilweise mit einer aggressiv gesetzten Toleranz. Betrachten Sie sie als günstigen Fall auf Bare Metal und nicht als Versprechen für Ihr System.

[
  {
    "label": "hackbench, 1 group, Xeon Sapphire Rapids",
    "gain_pct": 30.57
  },
  {
    "label": "schbench, 4 threads, p99 wakeup latency, Sapphire Rapids",
    "gain_pct": 37.78
  },
  {
    "label": "ChaCha20 throughput, AMD Genoa, aggressive tolerance",
    "gain_pct": 44
  }
]

Hackbench mit einer einzelnen Gruppe verbesserte sich um 30.57%. Der ChaCha20-Durchsatztest auf AMD Genoa verbesserte sich um 44%. Alle 3 Ergebnisse wurden auf Serverhardware mit mehreren LLCs ermittelt, die der Tester vollständig kontrollierte.

Ein Workload, der profitiert, weist typischerweise folgende Merkmale auf:

• Mehr als ein Thread in einem einzelnen Prozess, sodass es etwas zu gruppieren gibt.
• Tatsächliche gemeinsame Nutzung zwischen diesen Threads, sodass eine zwischen CPUs verschobene Cache-Zeile tatsächlich Kosten verursacht.
• Ein Working Set, das in eine einzelne LLC passt. Ein Prozess, der größer als der Cache ist, kann durch Verschieben keine Cache-Lokalität erhalten.
• Freie Kapazität auf dem Rechner, sodass der Scheduler tatsächlich entscheiden kann, wo der nächste Thread ausgeführt wird.

In folgenden Fällen gibt es dagegen nichts zu gewinnen:

• Ein Rechner, der bereits vollständig ausgelastet ist. Jede CPU ist beschäftigt, daher ist die Platzierung vorgegeben und die gemeldeten Verbesserungen fallen weg.
• Prozesse mit nur einem Thread sowie Pools unabhängiger Prozesse, die keine Daten gemeinsam nutzen.
• Ein Working Set, das deutlich größer als die LLC ist und das die vorsichtige Einstellung llc_aggr_tolerance absichtlich überspringt.
• Ein Knoten, der eine einzige LLC meldet. Dort wird das Feature überhaupt nicht aktiviert.

Es gibt auch Kosten, und die Patch-Serie legt diese offen. Das Erfassen der Belegung verursacht Arbeit im Kontext des Tasks. Bei einigen Durchläufen stieg dadurch die Anfragelatenz, weil diese Arbeit die Rückkehr des Tasks in den User Space verzögerte. Die Aggregation kann außerdem die Latenzschwankung erhöhen, selbst wenn der durchschnittliche Durchsatz steigt. Wenn für Sie die Tail-Latenz und nicht der Durchschnitt entscheidend ist, messen Sie Ihre eigene Tail-Latenz.

Sieht ein VPS-Gast davon etwas?

Zwei Fakten bestimmen die Antwort.

Erstens hängt die Funktion von der Topologie ab. Cache-bewusstes Load-Balancing wird nur aktiviert, wenn innerhalb eines NUMA-Knotens mehr als ein LLC vorhanden ist. Der Kernel erfasst dies während der Einrichtung der Topologie. Meldet ein Knoten nur ein LLC, bleibt der cache-bewusste Pfad unabhängig von den gesetzten Tunables inaktiv.

Zweitens entspricht die Cache-Topologie, die Ihr Gast liest, nicht der des Hosts. Sie wird durch das CPU-Modell bestimmt, das der Hypervisor präsentiert. Ein standardmäßiger KVM (kernel based virtual machine)-Gast erhält normalerweise nicht das reale L3-Layout des Hosts. Der Gast arbeitet daher mit einem vereinfachten Modell.

Prüfen Sie, was Ihr eigener Gast sieht:

systemd-detect-virt
lscpu --caches
cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u

index3 ist bei den meisten x86-CPUs der L3-Cache. Eine Zeile, in der alle vCPUs aufgeführt sind, bedeutet, dass der Gast ein einzelnes LLC sieht. Die Funktion kann dann nichts anordnen. No such file or directory bedeutet, dass dem Gast überhaupt kein L3-Cache präsentiert wurde. Der Gast behandelt dann eine niedrigere Cache-Ebene als seine letzte Ebene. Deren Grenzen wurden vom Hypervisor festgelegt und entsprechen nicht den Grenzen der Hardware.

Hinzu kommt die doppelte Scheduling-Ebene. Das ist der wichtige Vorbehalt für jeden Mandanten. Ihr Gast-Kernel verteilt Threads auf vCPUs. Der Host-Kernel verteilt diese vCPU-Threads auf physische Kerne. Ein Gast, der vier Threads gezielt auf vCPU 0 bis 3 gruppiert, äußert damit eine Präferenz für vier Threads auf dem Host. Der Host kann sie auf unterschiedliche physische Cache-Domänen verteilen und später verschieben. Die Entscheidung des Gasts ist nicht falsch. Sie ist nur nicht die endgültige Entscheidung. Das ist dieselbe Ebenengrenze, durch die auch die Steal Time entsteht, die ein ausgelasteter Nachbar auf Ihren vCPUs verursacht.

Wie wirkt sich diese Funktion also auf einen VPS-Mandanten aus? An zwei Stellen. Bei Tarifen mit realer statt synthetischer Topologie, etwa bei dedizierten Kernen oder größeren Instanzen mit durchgereichtem Layout, trifft der Gast-Scheduler eine Entscheidung über tatsächlich vorhandene Hardware. Und im eigenen Host-Kernel des Providers: Dort ist die cache-bewusste Platzierung Ihrer vCPU-Threads der Vorteil des Providers, nicht Ihrer. Das Cache-Layout unterscheidet sich außerdem je nach Architektur. Das ist eine weitere Variable beim Vergleich eines Arm-VPS mit einem x86-VPS.

Das Cache-Verhalten innerhalb eines Gasts zu messen, ist schwieriger als auf der physischen Hardware. perf stat -e cache-misses meldet häufig <not supported>, weil der Hypervisor die PMU (performance monitoring unit) nicht für Gäste verfügbar macht. Messen Sie stattdessen Durchsatz und Latenz Ihrer eigenen Anwendung. Verwenden Sie den debugfs-Regler als Umschalter zwischen den beiden Messläufen.

Prüfen, ob Ihr Kernel CONFIG_SCHED_CACHE enthält

uname -r
grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r) || echo 'not set in this build'
sudo ls /sys/kernel/debug/sched/ | grep -i llc

CONFIG_SCHED_CACHE=y bedeutet, dass Ihr Kernel mit dieser Option gebaut wurde. Eine Zeile mit # CONFIG_SCHED_CACHE is not set bedeutet, dass die Option in dieser Version vorhanden ist, Ihre Distribution sie jedoch deaktiviert hat. Überhaupt keine Ausgabe bedeutet normalerweise, dass der Kernel älter als diese Option ist. uname -r bestätigt das. Einige minimale Cloud-Images enthalten keine Datei /boot/config-*. Lesen Sie in diesem Fall stattdessen zcat /proc/config.gz aus. Das funktioniert nur, wenn der Kernel mit CONFIG_IKCONFIG_PROC gebaut wurde.

Die Zeile ls gibt die llc_*-Parameter aus, wenn das Feature einkompiliert ist. Wenn sie trotz CONFIG_SCHED_CACHE=y nichts ausgibt, hängen Sie zuerst debugfs mit sudo mount -t debugfs none /sys/kernel/debug ein.

Um Ihre Arbeitslast mit aktiviertem und deaktiviertem Feature zu vergleichen, speichern Sie zuerst den aktuellen Wert. Sie müssen ihn anschließend wiederherstellen:

sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance
sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'

Führen Sie Ihren Benchmark aus, schreiben Sie den notierten Wert zurück und führen Sie den Benchmark erneut aus. Änderungen über debugfs bleiben nach einem Reboot nicht erhalten. Das ist beim Testen erwünscht.

Wann wird ein Distributionskernel 7.2 enthalten?

Mainline ist nicht der Kernel, mit dem Ihre VPS startet. Die Version in uname -r stammt von Ihrer Distribution. Jede Distribution hat einen eigenen Weg von einer Mainline-Version bis zu Ihrem Server.

Fedora aktualisiert seine stabilen Releases während des Supportzeitraums auf neue Mainline-Kernel. Dort ist daher sudo dnf upgrade --refresh plus ein Reboot der gesamte Vorgang. Fedora ist normalerweise der erste Ort, an dem ein Mandant einen neuen Kernel testen kann. Diese Update-Frequenz gehört zu den Eigenschaften, für die Sie sich mit Fedora Server auf einer VPS entscheiden.

Ubuntu veröffentlicht mit jedem sechsmonatigen Release einen neuen Kernel. Anschließend stellt Ubuntu ihn über den HWE-Stack (Hardware Enablement) für das vorherige Long-Term-Support-Release (LTS) bereit. Im August 2026 installiert Ubuntu 24.04 LTS weiterhin 6.8 aus dem April 2024 als GA-Kernel. Der HWE-Stack wechselte im August 2025 zu 6.14 und im Februar 2026 zu 6.17. Das ist der realistische Zeitrahmen: Eine Mainline-Version aus dem August 2026 erreicht einen LTS-HWE-Stack ungefähr ein Jahr später.

apt-cache policy linux-generic-hwe-24.04
sudo apt install --install-recommends linux-generic-hwe-24.04

Debian stable behält während der gesamten Laufzeit des Releases einen Kernel bei. Neuere Kernel stehen über backports zur Verfügung. Diese aktivieren Sie paketweise:

echo 'deb http://deb.debian.org/debian trixie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list
sudo apt update
sudo apt install -t trixie-backports linux-image-amd64

Führen Sie danach einen Reboot durch. Prüfen Sie die Version mit uname -r und mit dem oben genannten grep. Ein neuer Kernel lässt sich nicht im laufenden Betrieb laden: Live-Kernel-Patching auf einer VPS ersetzt den Code einzelner Funktionen im laufenden Kernel. Es kann jedoch keine Strukturlayouts ändern und keine debugfs-Dateien hinzufügen. Cache-bewusstes Scheduling tut beides, weil es Felder zu mm_struct hinzufügt. Deshalb ist es erst nach dem Booten eines neuen Kernels verfügbar.

Zwei praktische Folgeschritte sind wichtig. Lassen Sie den alten Kernel bootfähig, bis der neue Ihre Last eine Weile zuverlässig verarbeitet. Dafür ist Festlegen des Bootkernels auf einer VPS vorgesehen. Überwachen Sie außerdem /boot. Die Bootpartition einer kleinen VPS ist nach einigen Kernel-Upgrades schnell voll. Das wird unter Alte Kernel unter Ubuntu bereinigen beschrieben.

Zum Abschluss ein realistischer Hinweis zu den Zuständigkeiten. Auf einer KVM-VPS gehört der Gastkernel Ihnen. Sie wählen ihn aus, booten ihn und können zu ihm zurückkehren. Der Hostkernel gehört Ihrem Provider. Keine Einstellung in Ihrem Gast ändert, welchen Scheduler der Hypervisor ausführt. Eine Release-Notiz zur Scheduler-Platzierung beschreibt für einen Mandanten daher nur die halbe Situation. Die von Ihnen kontrollierte Hälfte betrifft den Gast.

Verwendete Quellen für diese Seite

• Die Zusammenfassung des 7.2-Changelogs auf kernelnewbies.org für das Veröffentlichungsdatum 16 August 2026 und die Änderungen außerhalb des Schedulers.
• Die Berichte von LWN über die Serie zum cachebewussten Scheduling auf lwn.net/Articles/1041668 und lwn.net/Articles/1058288 für die debugfs-Einstellmöglichkeiten, den Mechanismus für Präferenzen pro Prozess und die genannten Benchmarkwerte.
• Der Patch, der das Feature anhand der Topologie aktiviert, "sched/cache: Introduce sched_cache_present", für die Regel, dass cachebewusstes Load-Balancing mehr als einen LLC in einem NUMA-Knoten benötigt.

Für die vorherige Version siehe die Änderungen im Linux-Kernel 7.1. Wie diese Versionsnummern entstanden sind, erfahren Sie in der Zeitleiste der Linux-Kernel-Historie.

FAQ

Macht cache-bewusstes Scheduling in Linux 7.2 eine VPS schneller?

In der Regel nicht allein. Die Funktion wird nur aktiviert, wenn ein NUMA-Knoten mehr als einen Last-Level-Cache meldet. Ein typischer KVM-Gast stellt dieses Layout jedoch nicht dar. Deshalb wird der Code nie aktiv. Wenn die Funktion aktiv wird, wird der Gast weiterhin zweimal geplant: Ihr Kernel wählt eine vCPU aus, und der Host-Kernel entscheidet, auf welchem physischen Kern der Thread dieser vCPU läuft. Dadurch kann der Host eine Cache-Entscheidung des Gasts wieder aufheben. Führen Sie cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u in Ihrem Gast aus. Eine Zeile für jede vCPU bedeutet, dass für die Funktion nichts zu arrangieren ist.

Wie prüfe ich, ob mein Kernel CONFIG_SCHED_CACHE enthält?

Führen Sie grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r) aus. CONFIG_SCHED_CACHE=y bedeutet, dass die Funktion einkompiliert ist. # CONFIG_SCHED_CACHE is not set bedeutet, dass Ihre Distribution sie deaktiviert hat. Keine Ausgabe bedeutet, dass der Kernel älter als diese Option ist. Wenn das Image keine Datei /boot/config-* enthält, versuchen Sie zcat /proc/config.gz. Diese Datei existiert nur bei Kerneln, die mit CONFIG_IKCONFIG_PROC erstellt wurden. Zur Laufzeit können Sie die Funktion mit sudo ls /sys/kernel/debug/sched/ | grep -i llc bestätigen. Dieser Befehl listet bei vorhandener Funktion die llc_*-Einstellungen auf.

Wie deaktiviere ich cache-bewusstes Scheduling ohne Neustart?

Schreiben Sie 0 in den Toleranz-Regler: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. Dadurch wird die Funktion zur Laufzeit deaktiviert. Das ist ein sauberer A/B-Schalter für einen Benchmark. Lesen Sie den aktuellen Wert zuerst mit sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance aus und schreiben Sie ihn anschließend zurück, da die Standardwerte zwischen Builds variieren. Nichts, was in debugfs geschrieben wird, bleibt nach einem Neustart erhalten. Wenn cat No such file or directory meldet, wurde die Funktion nicht in Ihren Kernel einkompiliert. Es gibt dann nichts zu deaktivieren.

Wann werden Ubuntu oder Debian einen auf 7.2 basierenden Kernel veröffentlichen?

Fedora aktualisiert stabile Releases auf neue Mainline-Kernel. Daher kommt die Version dort zuerst über ein normales dnf upgrade und einen Neustart. Ubuntu veröffentlicht mit jedem Release im Abstand von sechs Monaten neue Kernel und stellt sie über den HWE-Stack für das vorherige LTS bereit. Die historische Verzögerung beträgt ungefähr ein Jahr: Im August 2026 verwendet der HWE-Stack von 24.04 LTS den Kernel 6.17 vom Februar 2026, während der GA-Kernel weiterhin 6.8 ist. Debian stable behält für das Release einen Kernel bei und bietet neuere Kernel über trixie-backports an. Diese installieren Sie paketweise mit apt install -t trixie-backports linux-image-amd64.