Linux vs. Windows 11 – Warum Linux das Ressourcenmanagement schon immer besser macht

Als ich letzten Monat die Patchnotes zum neuesten Windows 11 Update überflogen habe, musste ich kurz innehalten. Da stand es, stolz präsentiert von Microsoft: das „Low Latency Profile„ – ein neues Feature, das die CPU kurzzeitig hochtaktet, sobald du das Startmenü öffnest oder eine App startest, damit das alles gefühlt schneller reagiert. Der Werbtext klang, als hätte Microsoft das Rad neu erfunden.

Ich habe dann meinen Kaffee genommen, nochmal gelesen – und laut gelacht. Nicht, weil das eine schlechte Idee ist. Sondern weil ich diesen „neuen Trick“ auf meinen Linux-Systemen seit Jahren nutze. Und weil er dort nicht mal einer Konfiguration bedarf, weil er einfach… funktioniert. Von Haus aus. Seit Kernel-Versionen, bei denen Windows XP noch aktuell war.

Lass mich dir erklären, warum das so ist – und wie du das Ganze unter Linux selbst in die Hand nehmen kannst.

Die Grundlagen: Was steckt überhaupt hinter CPU-Scaling?

Bevor wir tief einsteigen, müssen wir ein paar Begriffe klären. Eine moderne CPU läuft nicht einfach auf einer festen Taktfrequenz. Sie schläft, wacht auf, taktet hoch, drosselt runter – und das passiert je nach Last Dutzende Male pro Sekunde. Das klingt chaotisch, ist aber hochgradig clever: Warum soll dein Prozessor mit 5 GHz durch die Gegend feuern, wenn du gerade nur eine Textdatei tippst?

Dafür gibt es zwei zentrale Konzepte:

P-States (Performance States) beschreiben, auf welcher Taktfrequenz und Spannung die CPU gerade läuft. P0 ist der höchste Performance-Zustand (volle Power), höhere P-Nummern bedeuten niedrigere Frequenzen und weniger Stromverbrauch. Moderne CPUs von Intel und AMD haben davon dutzende, teilweise sogar kontinuierliche Übergänge dazwischen.

C-States (Idle States) hingegen greifen, wenn die CPU gerade gar nichts zu tun hat. C0 bedeutet aktiv, C1 ist der erste Schlafzustand (Takt angehalten, aber Spannung noch da), und C6 oder C10 sind Tiefschlafzustände, bei denen CPU-Kerne sich faktisch abschalten und erst nach einer kurzen Aufwachzeit wieder bereit sind. Je tiefer der C-State, desto mehr Energie sparst du – aber desto länger dauert auch das Aufwachen.

Und genau hier beginnt die Geschichte des Windows-Problems.

So macht es Linux – ein Deep-Dive in cpufreq und Governors

Linux hat für das Management dieser P-States ein eigenes Subsystem: cpufreq. Es ist der Vermittler zwischen dem Betriebssystem und dem Hardware-Treiber der CPU, und es arbeitet mit einem eleganten Konzept zusammen: den sogenannten Scaling Governors.

Ein Governor ist im Grunde eine Strategie. Er entscheidet, auf welche Taktfrequenz die CPU zu einem gegebenen Zeitpunkt gesetzt wird. Stell dir ihn wie den Dirigenten eines Orchesters vor: Das Orchester (deine CPU) kann sehr laut oder sehr leise spielen – der Governor gibt den Takt vor.

Die wichtigsten Governors im Überblick

performance ist der Bulldozer unter den Governors. Er setzt die CPU einfach dauerhaft auf die maximale Frequenz. Kein Nachdenken, keine Rücksicht auf Stromverbrauch. Das macht Sinn auf einem Render-Server im Rechenzentrum oder wenn du gerade ein CPU-intensives Game zockst und jeden Millisekunde brauchst.

powersave ist das genaue Gegenteil: minimale Frequenz, maximale Schonung. Auf einem Laptop im Akkubetrieb absolut sinnvoll, beim Gaming oder bei interaktiven Aufgaben aber eine echte Bremse.

ondemand war lange der Standard und ist konzeptuell schon deutlich smarter: Er schaut, wie ausgelastet die CPU ist, und skaliert die Frequenz entsprechend hoch. Problem: Er reagiert reaktiv und mit einer gewissen Trägheit. Erst wenn die Last schon da ist, taktet er hoch – und das kann bei kurzen, interaktiven Aufgaben (Menü öffnen, App starten) zu merkbaren Mikrorucklern führen.

schedutil ist der moderne Star – und mein persönlicher Favorit. Er ist seit Kernel 4.7 verfügbar und macht etwas, was die anderen Governors nicht können: Er schaut direkt in den CPU-Scheduler des Kernels. Konkret nutzt er die PELT-Metriken (Per-Entity Load Tracking) des Schedulers, um zu beurteilen, wie viel Last gerade anliegt und was in der nächsten Zeit zu erwarten ist. Das macht ihn nicht nur reaktionsschnell, sondern auch vorausschauend. Er taktet hoch, bevor die CPU anfängt zu schwitzen – und genauso schnell wieder runter.

Das Resultat: Schnelle Reaktion auf interaktive Aufgaben (genau wie Microsofts „Low Latency Profile“), kombiniert mit echtem Energiesparen im Idle-Betrieb. Kein Entweder-Oder.

Warum schedutil so gut ist

Ich hab das mal selbst durchgemessen: Mit ondemand hatte mein Desktop unter leichter Last Latenzen von 15–30 ms, bis die CPU auf volle Frequenz hochlief. Mit schedutil lag ich meistens unter 5 ms – weil der Governor nicht auf die Last wartet, sondern dem Scheduler zuhört, der bereits weiß, dass gleich Arbeit kommt.

Das ist kein Zufall, das ist Architektur. Und genau das fehlt Windows seit Jahren.

Der Windows-Ansatz – und warum er strukturell hinkt

Windows hat historisch gesehen eine andere Philosophie beim Ressourcenmanagement verfolgt. Statt eines flexiblen, kernel-nahen Subsystems gibt es auf Windows sogenannte Power Plans (Energiesparpläne). „Ausbalanciert“, „Höchstleistung“, „Energiesparmodus“ – du kennst sie vielleicht.

Diese Pläne sind eher grobe Schalter als ein feingranulares System. Sie konfigurieren zwar P-State-Grenzen, aber die eigentliche Entscheidungslogik ist tief im proprietären Windows-Scheduler versteckt und bietet kaum Einblick oder Anpassbarkeit.

Das eigentliche Problem liegt aber woanders: die Thread-Priorisierung bei GUI-Elementen. Windows gibt Prozessen und Threads eine statische oder semi-statische Priorität. Das Startmenü läuft beispielsweise als UWP-Prozess (Universal Windows Platform) mit einer bestimmten Basis-Priorität – und wenn die CPU gerade im niedrigen P-State schläft und erst hochtakten muss, wartet der UWP-Thread einfach. Kein Governor hört ihm zu. Kein Scheduler-Feedback-Kanal sagt der Hardware: „Hey, gleich wird’s interaktiv, fahr hoch.“

Was Microsoft mit dem „Low Latency Profile“ gemacht hat, ist im Wesentlichen: Sie haben erkannt, dass bestimmte Aktionen (Mausklick auf Start, App-Launch) ein Signal senden, das die CPU kurz auf Boost-Frequenz zwingt. Es ist ein hardcodierter Trigger – kein dynamisches Feedback-System. Clever gelöst für Windows, aber verglichen mit dem, was schedutil seit Jahren macht, ist es eine Krücke.

Das C-State-Problem

Hinzu kommt die C-State-Verwaltung. Windows ist historisch sehr konservativ bei C-States – aus gutem Grund, weil tiefe C-States auf mancher Hardware zu Instabilitäten führten. Aber das führt dazu, dass Windows CPUs oft in flachen C-States parkt, die weniger Strom sparen, als es möglich wäre.

Linux hingegen gibt dir (und dem Kernel) volle Kontrolle über C-State-Limits. Du kannst mit Tools wie cpupower genau festlegen, wie tief die CPU schlafen darf. Das zahlt sich auf Laptops direkt in der Akkulaufzeit aus.

Praxis-Teil: CPU-Governor unter Ubuntu optimal konfigurieren

Genug Theorie. Lass uns das in die Praxis umsetzen. Ich zeige dir, wie du unter Ubuntu (und den meisten anderen gängigen Distros) deinen aktuellen Governor ausließt, änderst und dauerhaft konfigurierst.

Schritt 1: Status prüfen

Zuerst schaust du, welche Governors verfügbar sind und welcher gerade aktiv ist:

bash

# Aktuellen Governor für alle CPU-Kerne anzeigen
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

# Verfügbare Governors anzeigen (für Kern 0)
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

# Aktuelle Frequenz aller Kerne (in kHz)
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq

Wenn du cpupower installiert hast (Paket: linux-tools-common bzw. cpupower), geht es noch übersichtlicher:

bash

sudo apt install linux-tools-common linux-tools-generic

# Status aller Kerne auf einen Blick
sudo cpupower frequency-info

# Frequency-Statistiken (wie lange auf welchem Takt)
sudo cpupower -c all frequency-info

Schritt 2: Governor wechseln

Governor für alle Kerne auf performance setzen (z.B. beim Gaming oder Rendern):

bash

sudo cpupower frequency-set -g performance

Zurück auf schedutil für den Alltag:

bash

sudo cpupower frequency-set -g schedutil

Oder manuell über sysfs (wenn cpupower nicht da ist):

bash

echo "schedutil" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Schritt 3: Frequenz-Grenzen setzen

Du kannst auch explizit festlegen, zwischen welchen Frequenzen die CPU skalieren darf. Nützlich, wenn du z.B. auf einem Laptop Wärme reduzieren willst, ohne ganz auf Performance-Governor zu verzichten:

bash

# Maximale Frequenz auf 3,0 GHz begrenzen (Wert in kHz)
sudo cpupower frequency-set -u 3000000

# Minimum auf 1,6 GHz setzen (verhindert zu tiefes Drosseln)
sudo cpupower frequency-set -d 1600000

Schritt 4: C-States kontrollieren

Mit cpupower kannst du auch die erlaubten C-States begrenzen. Wenn du maximale Reaktionsgeschwindigkeit willst und Strom keine Rolle spielt, kannst du tiefe C-States deaktivieren:

bash

# Nur bis C1 zulassen (kein Tiefschlaf)
sudo cpupower idle-set -D 2

# Wieder alle C-States zulassen
sudo cpupower idle-set -E

Warnung: Das kostet messbar Strom und Abwärme. Für Dauerbetrieb auf dem Laptop nicht empfohlen.

Schritt 5: Dauerhaft machen mit systemd

Änderungen via sysfs sind flüchtig – nach dem Reboot ist alles zurückgesetzt. Um die Governor-Einstellung dauerhaft zu machen, legst du einen systemd-Service an:

bash

sudo nano /etc/systemd/system/cpupower.service

Inhalt:

ini

[Unit]
Description=CPU Power Governor Setup
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower frequency-set -g schedutil
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Dann aktivieren:

bash

sudo systemctl enable cpupower.service
sudo systemctl start cpupower.service

Fertig. Ab sofort startet dein System immer mit dem gewünschten Governor.

Bonus: schedutil-Tuning für noch mehr Reaktionsschnelligkeit

schedutil hat einen konfigurierbaren Parameter: rate_limit_us. Er gibt an, wie oft der Governor maximal eine Frequenzentscheidung treffen darf (in Mikrosekunden). Der Standard liegt bei rund 1000 µs (1 ms). Für noch schnellere Reaktion auf kurze Lastspitzen kannst du ihn reduzieren:

bash

# Rate-Limit auf 0 setzen (kein Limit – maximale Reaktivität)
echo 0 | sudo tee /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us

Das macht den Governor aggressiver, kostet aber etwas mehr CPU-Overhead für die Governor-Entscheidungen selbst. Für interaktive Desktops lohnt es sich, für Server eher nicht.

Fazit: Open Source gewinnt – nicht durch Zufall, sondern durch Architektur

Was mich an der Windows-Ankündigung am meisten amüsiert, ist nicht die Lösung selbst – sie ist für Windows-Nutzer sicher eine echte Verbesserung. Was mich amüsiert, ist die Art, wie sie verkauft wird. Als wäre das neuartig. Als wäre es ein Durchbruch.

Linux hat das besser gemacht, weil es die CPU-Frequenzskalierung von Anfang an als Teil des Kernels konzipiert hat, nicht als nachträgliches UI-Feature. schedutil sitzt nicht neben dem Scheduler – er ist mit ihm verwoben. Er bekommt Feedback aus dem System, das Windows gar nicht hat, weil der Scheduler dort ein Black Box bleibt.

Das ist der fundamentale Unterschied: Linux gibt dir – und dem Kernel – Zugriff auf die Mechanismen. Windows gibt dir Einstellungsdialoge. Das ist nicht immer falsch, aber es ist ein anderer Ansatz. Und bei Ressourcenmanagement ist Transparenz und Kontrollierbarkeit nun mal ein enormer Vorteil.

Für mich persönlich läuft mein Desktop seit Jahren mit schedutil. Keine spürbare Trägheit, kein unnötiger Stromverbrauch im Idle, und wenn ich einen langen Compile-Lauf starte, ist die CPU in Millisekunden da. Kein manuelles Umschalten nötig.

Wenn du bisher noch nicht mit Governors gespielt hast: Probier es aus. Die Terminal-Befehle sind nicht komplizierter als ein apt install, und das Ergebnis ist messbar – sowohl in Benchmarks als auch im Alltag. Und falls du dir denkst: „Interessant, aber ich bleibe erstmal bei meinen aktuellen Einstellungen“ – dann zumindest weiß du jetzt, was unter der Haube passiert. Das ist es, was mich an Linux immer wieder begeistert: Ich kann reinschauen. Und ich kann eingreifen.