Zum Inhalt springen
CachyOS
Diese Seite ist veraltet. Bitte beachten Sie die neueste Dokumentation unter /configuration/sched-ext/

sched-ext Tutorial

Extensible Scheduler Class (besser bekannt als sched-ext) ist ein Linux-Kernel-Feature, das es ermöglicht, Kernel-Thread-Scheduler in BPF (Berkeley Packet Filter) zu implementieren und dynamisch zu laden. Im Wesentlichen erlaubt dies Endbenutzern, ihre Scheduler im Userspace zu ändern, ohne einen neuen Kernel kompilieren zu müssen, nur um einen anderen Scheduler zu haben.

  • Die Scheduler findest du in den Paketen scx-scheds und scx-scheds-git.

    Terminal-Fenster
    # Stabiler Branch + scx_loader und scxctl-Tools.
    sudo pacman -S scx-scheds scx-tools
    

    # Bleeding-Edge-Branch (Dieser Branch enthält die neuesten Änderungen aus dem Master-Branch.) + scx_loader und scxctl-Tools.
    sudo pacman -S scx-scheds-git scx-tools-git

Wie man den Scheduler startet und verwaltet

Abschnitt betitelt „Wie man den Scheduler startet und verwaltet“
  • Um den Scheduler zu starten, öffne dein Terminal und gib den folgenden Befehl ein:
    Beispiel für den Start von rusty
    sudo scx_rusty

Dadurch wird der Rusty-Scheduler gestartet und der Standard-Scheduler getrennt.

Um den Scheduler zu stoppen, drücke STRG + C. Der Scheduler wird dann gestoppt und der Standard-Kernel-Scheduler übernimmt wieder.

Scheduler-Anleitung: Profile und Anwendungsfälle

Abschnitt betitelt „Scheduler-Anleitung: Profile und Anwendungsfälle“

Da es viele Scheduler zur Auswahl gibt, wollen wir eine kleine Einführung zu den verfügbaren Schedulern geben.

Melde gerne jedes Problem oder Feedback in ihrem Scheduler-Repository.

Verwende scx_schedulername --help, um die verfügbaren Flags und eine kurze Beschreibung ihrer Funktion zu sehen.

Beispiel für Hilfe zu scx_rusty
scx_rusty --help

scx_bpfland

Abschnitt betitelt „scx_bpfland“

Entwickelt von: Andrea Righi (arighi GitHub)

Produktionsreif?

Ein vruntime-basierter sched_ext-Scheduler, der interaktive Workloads priorisiert. Sehr flexibel und einfach anzupassen.

Wenn Bpfland Entscheidungen darüber trifft, welche Kerne verwendet werden sollen, berücksichtigt es deren Cache-Layout und welche Kerne denselben L2/L3-Cache teilen, was zu weniger Cache-Misses = mehr Leistung führt.

  • Anwendungsfälle:
    • Gaming
    • Desktop-Nutzung
    • Multimedia-/Audioproduktion
    • Hervorragende Interaktivität unter intensiven Workloads
    • Energiesparen
    • Server

Scheduler-Modi

Abschnitt betitelt „Scheduler-Modi“
Niedrige Latenz
Abschnitt betitelt „Niedrige Latenz“
  • Kommandozeilen-Flags: -m performance -w
  • Beschreibung: Soll die Latenz auf Kosten des Durchsatzes verringern. Geeignet für Soft-Echtzeitanwendungen wie Audioverarbeitung und Multimedia.
Energiesparen
Abschnitt betitelt „Energiesparen“
  • Kommandozeilen-Flags: -s 20000 -m powersave -I 100 -t 100
  • Beschreibung: Priorisiert die Energieeffizienz. Bevorzugt weniger leistungsstarke Kerne (z. B. E-Kerne bei Intel).
Server
Abschnitt betitelt „Server“
  • Kommandozeilen-Flags: -s 20000 -S
  • Beschreibung: Priorisiert Aufgaben mit strikter Affinität. Diese Option kann den Durchsatz auf Kosten der Latenz erhöhen und ist besser für Server-Workloads geeignet.

scx_beerland

Abschnitt betitelt „scx_beerland“

Entwickelt von: Andrea Righi (arighi GitHub)

Produktionsreif?

scx_beerland ist ein Scheduler, der darauf ausgelegt ist, Lokalität und Skalierbarkeit zu priorisieren.

Priorisiert das Halten von Aufgaben auf derselben CPU, um die Cache-Lokalität zu wahren, und stellt gleichzeitig eine gute Skalierbarkeit über viele CPUs sicher, indem lokale DSQs (per-CPU-Runqueues) verwendet werden, wenn das System nicht ausgelastet ist.

  • Anwendungsfälle:
    • Cache-intensive Workloads
    • Systeme mit einer großen Anzahl von CPUs
    • Gaming: Es ist bekannt, dass es in bestimmten Spielen überraschend gut funktioniert, obwohl deine Ergebnisse variieren können
    • Server: Gut für allgemeine Server-Workloads aufgrund seiner Skalierbarkeits- und Lokalitätsoptimierungen.
    • Kann auch für die Desktop-Nutzung verwendet werden.

Scheduler-Modi

Abschnitt betitelt „Scheduler-Modi“

Momentan keine.

scx_rustland

Abschnitt betitelt „scx_rustland“

Entwickelt von: Andrea Righi (arighi GitHub)

Produktionsreif?

Für leistungskritische Produktionsszenarien werden andere Scheduler wahrscheinlich eine bessere Leistung zeigen, da das Auslagern aller Scheduling-Entscheidungen in den User-Space mit einem gewissen Preis verbunden ist (auch wenn dieser minimal ist).

Ein vollständig im User-Space implementierter Scheduler birgt jedoch das Potenzial für eine nahtlose Integration mit anspruchsvollen Bibliotheken, Tracing-Tools, externen Diensten (z. B. KI) usw.

Daher kann es Situationen geben, in denen die Vorteile den Overhead überwiegen und die Verwendung dieses Schedulers in einer Produktionsumgebung rechtfertigen.

Teilt Ähnlichkeiten mit bpfland, wurde mit der Absicht erstellt, leicht lesbar und verständlich zu sein, wie er aufgrund seiner Implementierung im Userspace funktioniert.

Denk daran, dass es einen leichten Durchsatznachteil gibt, wenn ein Userspace-Scheduler verwendet wird.

  • Anwendungsfälle:
    • Workloads mit geringer Latenz (Gaming, Videokonferenzen und Live-Streaming)
    • Desktop-Nutzung

scx_flash

Abschnitt betitelt „scx_flash“

Entwickelt von: Andrea Righi (arighi GitHub)

Produktionsreif?

Ein Scheduler, der sich darauf konzentriert, Fairness zwischen Aufgaben und Leistungsvorhersehbarkeit zu gewährleisten.

Er arbeitet nach einer Earliest Deadline First (EDF) Richtlinie, bei der jeder Aufgabe ein “Latenz”-Gewicht zugewiesen wird. Dieses Gewicht wird dynamisch angepasst, je nachdem, wie oft eine Aufgabe die CPU freigibt, bevor ihre volle Zeitscheibe aufgebraucht ist.

Aufgaben, die die CPU frühzeitig freigeben, erhalten ein höheres Latenzgewicht und werden gegenüber Aufgaben priorisiert, die ihre Zeitscheibe vollständig verbrauchen.

  • Anwendungsfälle:
    • Gaming
    • Latenzempfindliche Workloads wie Multimedia- oder Echtzeit-Audioverarbeitung
    • Bedarf an Reaktionsfähigkeit in überlasteten Situationen
    • Konsistenz in der Leistung
    • Server

Scheduler-Modi

Abschnitt betitelt „Scheduler-Modi“
Niedrige Latenz
Abschnitt betitelt „Niedrige Latenz“
  • Kommandozeilen-Flags: -m performance -w -C 0
  • Beschreibung: Soll die Latenz auf Kosten des Durchsatzes verringern. Geeignet für Soft-Echtzeitanwendungen wie Audioverarbeitung und Multimedia.
Gaming
Abschnitt betitelt „Gaming“
  • Kommandozeilen-Flags: -m all
  • Beschreibung: Optimiert für hohe Leistung in Spielen.
Energiesparen
Abschnitt betitelt „Energiesparen“
  • Kommandozeilen-Flags: -m powersave -I 10000 -t 10000 -s 10000 -S 1000
  • Beschreibung: Priorisiert die Energieeffizienz. Bevorzugt weniger leistungsstarke Kerne (z. B. E-Kerne bei Intel) und führt alle 10 ms einen erzwungenen Leerlaufzyklus ein, um die Energieeinsparung zu erhöhen.
Server
Abschnitt betitelt „Server“
  • Kommandozeilen-Flags: -m all -s 20000 -S 1000 -I -1 -D -L
  • Beschreibung: Für Server-Workloads optimiert. Tauscht Reaktionsfähigkeit gegen Durchsatz.

scx_cosmos

Abschnitt betitelt „scx_cosmos“

Entwickelt von: Andrea Righi (arighi GitHub)

  • Produktionsreif?

Leichter Scheduler, optimiert für die Beibehaltung der Task-zu-CPU-Lokalität.

Wenn das System nicht ausgelastet ist, priorisiert der Scheduler das Halten von Aufgaben auf derselben CPU mithilfe lokaler DSQs. Dies erhält nicht nur die Lokalität, sondern reduziert auch die Sperrkonflikte im Vergleich zu gemeinsamen DSQs, was eine gute Skalierbarkeit über viele CPUs ermöglicht.

  • Anwendungsfälle:
    • Allzweck-Scheduler: Der Scheduler sollte sich sowohl für Server-Workloads als auch für Desktop-Workloads anpassen.

Scheduler-Modi

Abschnitt betitelt „Scheduler-Modi“
Auto
Abschnitt betitelt „Auto“
  • Kommandozeilen-Flags: -d
  • Beschreibung: Deaktiviert verzögerte Wakeups. Reduziert den Durchsatz und die Leistung für bestimmte Workloads und verringert gleichzeitig den Stromverbrauch.
Gaming
Abschnitt betitelt „Gaming“
  • Kommandozeilen-Flags: -c 0 -p 0
  • Beschreibung: Deaktiviert die CPU-Lastverfolgung und erzwingt immer ein Deadline-basiertes Scheduling, um die Reaktionsfähigkeit zu verbessern.
Energiesparen
Abschnitt betitelt „Energiesparen“
  • Kommandozeilen-Flags: -m powersave -d -p 5000
  • Beschreibung: Priorisiert die Energieeffizienz. Bevorzugt weniger leistungsstarke Kerne (z. B. E-Kerne bei Intel) und deaktiviert verzögerte Wakeups, was den Durchsatz reduziert und die Energieeffizienz erhöht. Die CPU-Lastabfrage wird auf 5 ms erhöht.
Niedrige Latenz
Abschnitt betitelt „Niedrige Latenz“
  • Kommandozeilen-Flags: -m performance -c 0 -p 0 -w
  • Beschreibung: Soll die Latenz auf Kosten des Durchsatzes verringern. Geeignet für Soft-Echtzeitanwendungen wie Audioverarbeitung und Multimedia. Erzwingt immer Deadline-basiertes Scheduling und synchrone Wake-up-Optimierungen, um die Leistungsvorhersehbarkeit zu verbessern.
Server
Abschnitt betitelt „Server“
  • Kommandozeilen-Flags: -s 20000
  • Beschreibung: Aktiviert die Adressraumaffinität, um die Lokalität und Leistung bei bestimmten cache-sensitiven Workloads zu verbessern. Die Abfrage wird auf 20 ms erhöht.

scx_lavd

Abschnitt betitelt „scx_lavd“

Entwickelt von: Changwoo Min (multics69 GitHub).

  • Produktionsreif?

Kurze Einführung in LAVD von Changwoo:

LAVD ist ein neuer Scheduling-Algorithmus, der sich noch in der Entwicklung befindet. Er ist motiviert durch Gaming-Workloads, die latenzkritisch und kommunikationsintensiv sind. Er zielt darauf ab, Latenzspitzen zu minimieren, während ein insgesamt guter Durchsatz und eine faire Nutzung der CPU-Zeit unter den Aufgaben beibehalten werden.

  • Anwendungsfälle:
    • Gaming
    • Audioproduktion
    • Latenzempfindliche Workloads
    • Desktop-Nutzung
    • Hervorragende Interaktivität unter intensiven Workloads
    • Energiesparen

Eine der wichtigsten und genialsten Fähigkeiten, die LAVD beinhaltet, ist die Core Compaction. die ohne auf technische Details einzugehen: Wenn die CPU-Auslastung < 50% ist, laufen die derzeit aktiven Kerne länger und mit einer höheren Frequenz. In der Zwischenzeit bleiben die inaktiven Kerne für eine viel längere Dauer im C-State (Ruhezustand), was zu einem geringeren Gesamtstromverbrauch führt.

Scheduler-Modi
Abschnitt betitelt „Scheduler-Modi“
Gaming & Niedrige Latenz
Abschnitt betitelt „Gaming & Niedrige Latenz“
  • Kommandozeilen-Flags: --performance
  • Beschreibung: Maximiert die Leistung durch die Nutzung aller verfügbaren Kerne und priorisiert physische Kerne.
Energiesparen
Abschnitt betitelt „Energiesparen“
  • Kommandozeilen-Flags: --powersave
  • Beschreibung: Minimiert den Stromverbrauch bei angemessener Leistung. Priorisiert effiziente Kerne und Threads gegenüber physischen Kernen.

scx_rusty

Abschnitt betitelt „scx_rusty“

Entwickelt von: David Vernet (Byte-Lab GitHub)

  • Produktionsreif?
    • Ja. Wenn er richtig eingestellt ist.

Rusty bietet eine breite Palette von Funktionen, die seine Fähigkeiten erweitern und eine größere Flexibilität für verschiedene Anwendungsfälle bieten. Eine dieser Funktionen ist die Einstellbarkeit, die es dir ermöglicht, Rusty an deine Vorlieben und spezifischen Anforderungen anzupassen.

  • Anwendungsfälle:
    • Gaming
    • Latenzempfindliche Workloads
    • Desktop-Nutzung
    • Multimedia-/Audioproduktion
    • Hervorragende Interaktivität unter intensiven Workloads
    • Energiesparen

scx_p2dq

Abschnitt betitelt „scx_p2dq“
  • Produktionsreif?
    • Ja. Wenn er für deinen spezifischen Workload und deine Hardware richtig eingestellt ist.

Entwickelt von: Daniel Hodges (hodgesds GitHub)

Ein Allzweck-Scheduler, der sich auf “Pick Two”-Lastausgleich zwischen LLCs konzentriert. Erhält eine hohe Cache-Lokalität und Work Conservation bei angemessener Latenz.

  • Anwendungsfälle:
    • Server
    • Desktop-Umgebungen
    • Gaming (mit etwas manuellem Tuning)

Scheduler-Modi

Abschnitt betitelt „Scheduler-Modi“
Gaming
Abschnitt betitelt „Gaming“
  • Kommandozeilen-Flags: --task-slice true -f --sched-mode performance
  • Beschreibung: Sorgt für eine gleichmäßigere Leistung beim Zocken und bevorzugt die leistungsstärkeren Kerne für die Aufgabenplanung.
Low Latency (Geringe Latenz)
Abschnitt betitelt „Low Latency (Geringe Latenz)“
  • Kommandozeilen-Flags: -y -f --task-slice true
  • Beschreibung: Verringert die Latenz, indem interaktive Aufgaben stärker an die CPU gebunden werden, der sie zugewiesen wurden, und erhöht die Stabilität der “Slice Time”.
Power Save (Energiesparmodus)
Abschnitt betitelt „Power Save (Energiesparmodus)“
  • Kommandozeilen-Flags: --sched-mode efficiency
  • Beschreibung: Verbessert die Energieeffizienz, indem energieeffiziente Kerne bevorzugt werden.
Server
Abschnitt betitelt „Server“
  • Kommandozeilen-Flags: --keep-running
  • Beschreibung: Verbessert Server-Workloads, indem Aufgaben auch über ihre zugewiesene Zeit hinaus laufen dürfen, wenn die CPU im Leerlauf ist.

scx_tickless

Abschnitt betitelt „scx_tickless“

Entwickelt von: Andrea Righi (arighi Github)

  • Für den Produktionseinsatz bereit?
    • Dieser Scheduler ist noch experimentell und wird nicht für den produktiven Einsatz empfohlen.

scx_tickless ist ein serverorientierter Scheduler, der für Cloud Computing, Virtualisierung und High-Performance-Computing-Workloads entwickelt wurde.

Der Scheduler leitet alle Planungsereignisse durch einen Pool von primären CPUs, die für diese Aufgaben zuständig sind. Das ermöglicht es, den “Tick” des Schedulers auf anderen CPUs zu deaktivieren, was das “OS-Rauschen” reduziert.

  • Anwendungsfälle:
    • Cloud Computing
    • Virtualisierung
    • High-Performance-Computing-Workloads
    • Server

Scheduler-Modi

Abschnitt betitelt „Scheduler-Modi“
Gaming
Abschnitt betitelt „Gaming“
  • Kommandozeilen-Flags: -f 5000 -s 5000
  • Beschreibung: Verbessert die Gaming-Leistung, indem der Scheduler häufiger CPU-Konflikte erkennt und Kontextwechsel mit einer kürzeren “Time Slice” auslöst.
Power Save (Energiesparmodus)
Abschnitt betitelt „Power Save (Energiesparmodus)“
  • Kommandozeilen-Flags: -f 50
  • Beschreibung: Verbessert die Energieeffizienz, indem die Überprüfung auf Konflikte seltener stattfindet.
Low Latency (Geringe Latenz)
Abschnitt betitelt „Low Latency (Geringe Latenz)“
  • Kommandozeilen-Flags: -f 5000 -s 1000
  • Beschreibung: Ähnlich wie das Gaming-Profil, aber mit einer noch kürzeren “Slice”.
Server
Abschnitt betitelt „Server“
  • Kommandozeilen-Flags: -f 100
  • Beschreibung: Reduziert, wie oft der Scheduler nach CPU-Konflikten sucht, um den Durchsatz auf Kosten der Reaktionsfähigkeit zu verbessern.

Konfiguration und Leistungstests

Abschnitt betitelt „Konfiguration und Leistungstests“

LAVD Autopilot & Autopower

Abschnitt betitelt „LAVD Autopilot & Autopower“

Zitate von Changwoo Min:

  • Im Autopilot-Modus passt der Scheduler seinen Energiemodus (Powersave, Balanced oder Performance) an die Systemlast an, insbesondere an die CPU-Auslastung.

  • Autopower: Entscheidet automatisch über den Energiemodus des Schedulers basierend auf dem Energieprofil des Systems, auch bekannt als EPP (Energy Performance Preference).

Terminal-Fenster
# Autopower kann mit dem folgenden Flag aktiviert werden:
--autopower
# z.B.:
scx_lavd --autopower

ananicy-cpp & sched-ext

Abschnitt betitelt „ananicy-cpp & sched-ext“

Um ananicy-cpp zu deaktivieren/stoppen, führe den folgenden Befehl aus:

Terminal-Fenster
systemctl disable --now ananicy-cpp

Umschalten der Energieprofile mit scx_loader

Abschnitt betitelt „Umschalten der Energieprofile mit scx_loader“

Das Ganze ist im Paket power-profiles-daemon von CachyOS drin, das einen eigenen Patch mitbringt, um das Umschalten der scx_loader-Energieprofile zu ermöglichen.

  • Wenn scx_loader gerade läuft und du game-performance nutzt, wird der aktive Scheduler automatisch auf das „Gaming“-Profil umgeschaltet, sobald du ein Spiel startest. Wenn du das Spiel wieder schließt, geht’s zurück zum Standardprofil.
  • Wenn du zwischen den Energieprofilen wechselst, zum Beispiel in KDE Plasma oder GNOME über den Umschalter für Energieprofile, schaltet scx_loader automatisch zum passenden Scheduler-Profil um:
Power ProfileScheduler Profile
Power SaverPower Save
BalancedAuto
PerformanceGaming

Benchmarking und Vergleich von Schedulern mit dem cachyos-benchmarker

Abschnitt betitelt „Benchmarking und Vergleich von Schedulern mit dem cachyos-benchmarker“

Das Tool cachyos-benchmarker bietet eine einfache Möglichkeit, die Leistung verschiedener CPU-Scheduler zu bewerten und zu vergleichen.

Es führt eine umfassende Suite von Benchmarks durch, um die CPU-, Speicher- und Gesamtsystemleistung unter verschiedenen Arbeitslasten zu messen.

Die folgenden Benchmarks sind enthalten:

TestMisstTool
stress-ng cpu-cache-memCPU-, Cache- und Speicherleistungstress-ng
FFmpeg-KompilierungParallele Build-Leistungmake
x265-KodierungVideokodierungs-Durchsatzx265
argon2-HashingMultithreaded-Passwort-Hashingargon2
perf sched msgKontextwechsel- und IPC-Leistungperf
perf memcpySpeicherdurchsatz memcpy()perf
PrimzahlberechnungGanzzahl-Arithmetik und Parallelitätprimesieve
NAMDMolekulardynamik (wissenschaftliche Arbeitslast)namd3
Blender-Renderreines CPU-3D-Renderingblender
xz-KompressionKompressionsdurchsatzxz
Kernel-defconfig-BuildKernel-Kompilierungsleistungmake
y-cruncherMathematische Präzision und Speicherbelastungy-cruncher

cachyos-benchmarker kann für verschiedene Zwecke verwendet werden, darunter:

  • Testen der Scheduler-Stabilität Führe die gesamte Benchmark-Suite aus, um Hänger, Abstürze oder Regressionen zu erkennen, die durch Scheduler-Änderungen eingeführt wurden. Wenn du scx_loader verwendest, kannst du im Falle eines Hängers oder Absturzes Protokolle mit folgendem Befehl sammeln:
    Terminal-Fenster
    journalctl --unit scx_loader.service --boot 0 > crash.log
    Dadurch wird eine Datei namens crash.log in deinem aktuellen Verzeichnis erstellt.
  • Vergleich der Scheduler-Leistung
    • Bewerte Leistungsunterschiede zwischen Schedulern. z.B. BPFLAND vs. LAVD
  • Messen des Effekts von Kernel- oder Scheduler-Updates
    • Vergleiche Durchläufe vor und nach dem Anwenden von Patches oder Versionsänderungen, um Leistungsregressionen oder -verbesserungen zu prüfen.
  • Testen von Konfigurationsanpassungen
    • Bewerte die Auswirkungen von Änderungen wie CPU-Governor-Einstellungen, SMT-Umschaltung oder modifizierten Scheduler-Flags.

Anforderungen

Abschnitt betitelt „Anforderungen“
  • 4 GB RAM oder mehr
  • Mindestens 8 GB freier Speicherplatz
  • Zeit und Geduld – der vollständige Benchmark kann auf langsameren Systemen über eine Stunde dauern

Installation

Abschnitt betitelt „Installation“

Um cachyos-benchmarker zu installieren, führe den folgenden Befehl aus:

Terminal-Fenster
sudo pacman -S cachyos-benchmarker

Ausführen des Benchmarks

Abschnitt betitelt „Ausführen des Benchmarks“
  1. Führe cachyos-benchmarker aus:
    Terminal-Fenster
    cachyos-benchmarker ~/cachyos-benchmarker/
    # Du kannst ~/cachyos-benchmarker/ durch ein beliebiges Verzeichnis ersetzen, in dem die Protokolle gespeichert werden sollen.
  2. Warte, bis die Vorbereitungsschritte abgeschlossen sind.
  3. Folge den Anweisungen:
    • Do you want to drop page cache now? Root privileges needed! (y/N) y (Möchtest du jetzt den Page-Cache leeren? Root-Rechte erforderlich!)
    • Please enter a name for this run, or leave empty for default: (Bitte gib einen Namen für diesen Durchlauf ein oder lass das Feld für den Standardnamen leer:)
  4. Warte, bis die Tests abgeschlossen sind.
  5. Sobald der Vorgang abgeschlossen ist, geschieht Folgendes:
    • Erstellung einer Protokolldatei mit einem Namen wie benchie_<name>_<DATUM>.log, die detaillierte Informationen über den Benchmark-Lauf enthält.
      • Beispiel: benchie_p2dq_2025-09-29-2115.log
      • Das Skript benchmark_scraper.py wird automatisch ausgeführt, um einen zusammenfassenden Bericht im HTML-Format zu erstellen.
      • Was macht das Skript?:
        • Liest alle benchie_*.log-Dateien im angegebenen Verzeichnis.
        • Extrahiert die Benchmark-Namen, -Zeiten und -Werte.
        • Sortiert oder fasst sie zusammen.
        • Gibt eine saubere Zusammenfassung der Ergebnisse in deinem Terminal aus und erstellt eine HTML-Datei, die in einem Browser geöffnet werden kann.
          Beispiel für die Terminal-Ausgabe:
          stress-ng cpu-cache-mem: 15.26
          y-cruncher pi 1b: 31.23
          perf sched msg fork thread: 8.892
          perf memcpy: 13.53
          namd 92K atoms: 53.54
          calculating prime numbers: 11.126
          argon2 hashing: 6.62
          ffmpeg compilation: 53.38
          xz compression: 61.13
          kernel defconfig: 130.73
          blender render: 96.29
          x265 encoding: 24.99
          

          Total time (s): 506.72
          Total score: 70.71
          

          Name: p2dq
          Date: 2025-09-29-2115
          

          System:    Kernel: 6.17.0-1.1-cachyos-p2dq arch: x86_64 bits: 64
                     Desktop: KDE Plasma v: 6.4.5 Distro: CachyOS
          Memory:    System RAM: total: 32 GiB available: 30.61 GiB used: 7.54 GiB (24.6%)
                     Device-1: Channel-A DIMM 0 type: LPDDR5 size: 8 GiB speed: 7500 MT/s
                     Device-2: Channel-B DIMM 0 type: LPDDR5 size: 8 GiB speed: 7500 MT/s
                     Device-3: Channel-C DIMM 0 type: LPDDR5 size: 8 GiB speed: 7500 MT/s
                     Device-4: Channel-D DIMM 0 type: LPDDR5 size: 8 GiB speed: 7500 MT/s
          CPU:       Info: 8-core model: AMD Ryzen 7 8845HS w/ Radeon 780M Graphics bits: 64 type: MT MCP cache: L2: 8 MiB
                     Speed (MHz): avg: 3366 min/max: 419/5138 cores: 1: 3366 2: 3366 3: 3366 4: 3366 5: 3366 6: 3366 7: 3366 8: 3366 9: 3366 10: 3366 11: 3366 12: 3366 13: 3366 14: 3366 15: 3366 16: 3366
          

          SCX Scheduler: p2dq_1.0.21_gf90c2aa1_dirty_x86_64_unknown_linux_gnu
          

          SCX Version: p2dq_1.0.21_gf90c2aa1_dirty_x86_64_unknown_linux_gnu
          

           Version         : 0.5.1-1
          HTML-Beispiel eines Testergebnisses, das zwei verschiedene Branches desselben Schedulers vergleicht:
  6. Um zwei oder mehr Durchläufe zu vergleichen, lege die .log-Dateien vor dem Ausführen von benchmark_scraper.py in dasselbe Verzeichnis. Das Tool erkennt und vergleicht sie automatisch im HTML-Bericht.

Testen der Scheduler-Latenz mit schbench

Abschnitt betitelt „Testen der Scheduler-Latenz mit schbench“

schbench ist ein Scheduler-Benchmark, der entwickelt wurde, um die Scheduler-Latenz unter einer simulierten serverähnlichen Arbeitslast zu messen. Es erzeugt eine konfigurierbare Anzahl von “Worker”- und “Message”-Threads, bei denen die Message-Threads wiederholt die Worker-Threads aufwecken. Durch die Messung der Latenzverteilung vom Aufwecken bis zur Ausführung dieser Worker-Threads liefert es wichtige Einblicke in die Fähigkeit eines Kernels, mit Thread-Aufweckvorgängen, Lastausgleich und CPU-Konflikten umzugehen, insbesondere unter Last.

Anwendungsfälle

Abschnitt betitelt „Anwendungsfälle“

Du kannst schbench verwenden, um:

  • Scheduler-Latenz zu bewerten: Finde heraus, wie schnell Threads nach dem Aufwecken eingeplant werden.
  • Aufweckleistung zwischen Schedulern zu vergleichen: Entdecke Verbesserungen oder Regressionen bei Kontextwechseln und Aufwecklatenz.
  • Die Auswirkung von Kernel- oder Scheduler-Patches zu testen: Bewerte, ob Optimierungen oder Updates die Fairness und Reaktionsfähigkeit des Schedulings beeinflussen.

Installation

Abschnitt betitelt „Installation“

schbench ist in den CachyOS-Repositories verfügbar:

Terminal-Fenster
sudo pacman -S schbench

Ausführen des Benchmarks

Abschnitt betitelt „Ausführen des Benchmarks“

Eine einfache Möglichkeit, schbench für einen allgemeinen Latenztest auszuführen, ist:

Terminal-Fenster
schbench -m 2 -t 8 -r 60

Dieses Beispiel führt aus:

  • 2 Message-Threads (-m 2)
  • 8 Worker-Threads pro Message-Thread (-t 8)
  • für eine Gesamtlaufzeit von 60 Sekunden (-r 60)

Du kannst diese Werte je nach Anzahl deiner CPU-Kerne und dem gewünschten Lastniveau anpassen.

Hier ist eine Tabelle, die einige der wichtigsten Optionen erklärt:

OptionBeschreibung
-C, --calibrateKalibrierung durchführen und Zeitmessung berichten (kein Benchmark).
-L, --no-lockingSpinlocks während der CPU-Arbeit deaktivieren (Standard: Sperren aktiviert).
-m, --message-threads <n>Anzahl der Message-Threads (Standard: 1).
-t, --threads <n>Worker-Threads pro Message-Thread (Standard: Anzahl der CPUs).
-r, --runtime <sec>Benchmark-Dauer (Standard: 30).
-F, --cache_footprint <KB>Größe des Cache-Footprints (Standard: 256).
-n, --operations <count>Anzahl der auszuführenden “Denkzeit”-Operationen (Standard: 5).
-A, --auto-rpsRPS automatisch erhöhen, bis das CPU-Auslastungsziel erreicht ist.
-R, --rps <count>Modus “Anfragen pro Sekunde”.
-p, --pipe <bytes>Simuliert einen Pipe-Übertragungstest.
-w, --warmuptime <sec>Aufwärmdauer vor dem Sammeln von Statistiken (Standard: 0).
-i, --intervaltime <sec>Intervall zum Drucken von Latenzen (Standard: 10).
-z, --zerotime <sec>Intervall zum Zurücksetzen der Latenzstatistiken (Standard: nie).

Die Ausgabe verstehen

Abschnitt betitelt „Die Ausgabe verstehen“

Nach jedem Durchlauf gibt schbench Latenzperzentile aus, wie hier:

Beispiel für die Ausgabe
Terminal-Fenster
Wakeup Latencies percentiles (usec) runtime 10 (s) (2406 total samples)
  50.0th: 60         (648 samples)
  90.0th: 2034       (968 samples)
* 99.0th: 4104       (211 samples)
  99.9th: 10128      (22 samples)
  min=1, max=10308
Request Latencies percentiles (usec) runtime 10 (s) (2394 total samples)
  50.0th: 49216      (726 samples)
  90.0th: 69760      (954 samples)
* 99.0th: 166656     (212 samples)
  99.9th: 273920     (21 samples)
  min=11770, max=334247
RPS percentiles (requests) runtime 10 (s) (11 total samples)
  20.0th: 234        (3 samples)
* 50.0th: 238        (3 samples)
  90.0th: 241        (4 samples)
  min=230, max=248
current rps: 230.99
Wakeup Latencies percentiles (usec) runtime 10 (s) (2406 total samples)
  50.0th: 60         (648 samples)
  90.0th: 2034       (968 samples)
* 99.0th: 4104       (211 samples)
  99.9th: 10128      (22 samples)
  min=1, max=10308
Request Latencies percentiles (usec) runtime 10 (s) (2406 total samples)
  50.0th: 49216      (729 samples)
  90.0th: 69760      (956 samples)
* 99.0th: 165632     (212 samples)
  99.9th: 273920     (22 samples)
  min=11770, max=334247
RPS percentiles (requests) runtime 10 (s) (11 total samples)
  20.0th: 234        (3 samples)
* 50.0th: 238        (3 samples)
  90.0th: 241        (4 samples)
  min=230, max=248
average rps: 240.60
Wie man die Ergebnisse interpretiert
Abschnitt betitelt „Wie man die Ergebnisse interpretiert“
  • Wakeup Latencies (Aufwecklatenzen):
    • Misst, wie schnell Threads aufwachen, nachdem sie ein Signal erhalten haben.
      • Niedrigere Werte hier (insbesondere das 99. Perzentil) bedeuten, dass der Scheduler reaktionsschneller ist.
  • Request Latencies (Anforderungslatenzen):
    • Stellt die Zeit dar, die benötigt wird, um Anfragen zwischen Threads abzuschließen.
      • Eine niedrigere Latenz deutet auf eine bessere Kommunikation zwischen den Threads und eine höhere Scheduling-Effizienz hin.
  • RPS (Requests Per Second - Anfragen pro Sekunde):
    • Zeigt den aufrechterhaltenen Durchsatz:
      • Ein höherer durchschnittlicher RPS-Wert zeigt an, dass der Scheduler unter der gegebenen Konfiguration mehr Arbeit pro Sekunde bewältigen kann.

Zusammenfassend:

  • Ein guter Scheduler zeigt niedrige Aufweck- und Anforderungslatenzen mit konstanten RPS-Werten.
  • Ein weniger effizienter Scheduler kann hohe Latenzspitzen oder instabile RPS-Werte im Laufe der Zeit aufweisen.

Empfehlungen für das Benchmarking von Spielen

Abschnitt betitelt „Empfehlungen für das Benchmarking von Spielen“

Wenn du Spiele benchmarken möchtest, um die Leistung verschiedener Scheduler zu vergleichen, findest du hier einige Tipps, um die genauesten Ergebnisse zu erhalten:

  • Nutze eingebaute Benchmarks: Viele moderne Spiele verfügen über integrierte Benchmark-Tools. Diese sind so konzipiert, dass sie konsistente Ergebnisse liefern, indem sie bei jedem Durchlauf dieselbe Abfolge von Ereignissen ausführen.
    • Schau dir diese Website für eine Liste von Spielen an, die eingebaute Benchmarks enthalten.
  • Konsistente Einstellungen: Stelle sicher, dass die Spieleinstellungen (Auflösung, Grafikqualität usw.) bei jedem Testlauf identisch sind.
  • Schließe Hintergrundanwendungen: Andere im Hintergrund laufende Anwendungen können die Leistung beeinträchtigen. Schließe unnötige Programme, um ihren Einfluss zu minimieren.
  • Wenn du keinen eingebauten Benchmark verwendest, versuche, bei jedem Testlauf dieselben Aktionen im Spiel auszuführen. Dies könnte das Verfolgen desselben Pfades, die Teilnahme an ähnlichen Kampfszenarien oder die Durchführung derselben Aufgaben umfassen.
    • Schon das Zielen auf eine andere Stelle kann zu unterschiedlichen Leistungsergebnissen führen.
  • Mehrere Durchläufe: Führe mehrere Benchmark-Durchläufe durch und bilde den Durchschnitt, um Schwankungen auszugleichen.
  • Verwende Leistungsüberwachungstools: Tools wie MangoHud oder GOverlay können Echtzeit-Leistungsmetriken wie FPS, Frame-Zeiten und CPU/GPU-Auslastung liefern.
  • Nutze Tastenkombinationen oder Makros:
    • Ein Beispiel ist die Erstellung einer Tastenkombination, mit der du im Spiel zwischen verschiedenen Schedulern wechseln oder deren Modi spontan ändern kannst.
      • Dies kann mit einem Tool wie scxctl oder durch das Erstellen eigener Skripte erfolgen, die den aktiven Scheduler und seinen Modus ändern.

Hochladen und Teilen deiner Benchmarks

Abschnitt betitelt „Hochladen und Teilen deiner Benchmarks“

Diese Website enthält eine Liste von Benchmarks, die von der Community mit verschiedenen Schedulern oder beim Testen verschiedener Einstellungen durchgeführt wurden.

Um deine eigenen Benchmarks hochzuladen, musst du dein Discord-Konto mit der Website verknüpfen, und dann kannst du deine eigenen Benchmarks einreichen.

Klicke dann auf die Schaltfläche New benchmark und fülle die erforderlichen Informationen aus.

  • Du kannst mehrere Ergebnisse für dasselbe Spiel mit verschiedenen Schedulern oder Einstellungen hochladen.
  • Akzeptiert sowohl MangoHud- als auch Afterburner-Protokolle.
  • Ermöglicht die Suche nach Titel oder Beschreibung.

Umstieg von scx.service auf scx_loader: Eine umfassende Anleitung

Abschnitt betitelt „Umstieg von scx.service auf scx_loader: Eine umfassende Anleitung“

Beginnen wir mit einem genauen Vergleich der Dateistruktur von scx.service mit der Konfigurationsdateistruktur von scx_loader.

Wenn du zuvor LAVD mit dem alten scx.service wie im folgenden Beispiel ausgeführt hast:

scx.service Dateistruktur
# Liste der scx_scheduler: scx_bpfland scx_central scx_flash scx_lavd scx_layered scx_nest scx_qmap scx_rlfifo scx_rustland scx_rusty scx_simple scx_userland
SCX_SCHEDULER=scx_lavd


# Setze benutzerdefinierte Flags für den Scheduler
SCX_FLAGS='--performance'

Dann wird das Äquivalent in der Konfigurationsdatei von scx_loader so aussehen:

scx_loader Dateistruktur
default_sched = "scx_lavd"
default_mode = "Auto"


[scheds.scx_lavd]
auto_mode = ["--performance"]

Weitere Informationen zur Konfiguration der scx_loader-Datei findest du hier

Folge der nachstehenden Anleitung für einen einfachen Übergang vom scx systemd service zum neuen scx_loader-Dienstprogramm.

  1. Deaktivieren von scx.service zugunsten des scx_loader.service
     systemctl disable --now scx.service && systemctl enable --now scx_loader.service
  2. Erstellen der Konfigurationsdatei für den scx_loader und Hinzufügen der Standardstruktur
    # Der Micro-Editor wird eine neue Datei erstellen.
    sudo micro /etc/scx_loader.toml
    # Füge die folgenden Zeilen hinzu:
    

    default_sched = "scx_bpfland" # Bearbeite diese Zeile mit dem Scheduler, den scx_loader beim Booten starten soll
    default_mode = "Auto" # Mögliche Werte: "Auto", "Gaming", "LowLatency", "PowerSave".
    

    # Drücke STRG + S, um die Änderungen zu speichern, und STRG + Q, um Micro zu beenden.
  3. Neustarten des scx_loader
    systemctl restart scx_loader.service
    • Du bist fertig, der scx_loader wird nun den gewünschten Scheduler laden und starten.

Debugging im scx_loader

Abschnitt betitelt „Debugging im scx_loader“
  • Dienststatus überprüfen
    systemctl status scx_loader.service
  • Alle Log-Einträge des Dienstes anzeigen
    journalctl -u scx_loader.service
  • Nur die Logs der aktuellen Sitzung anzeigen.
    journalctl -u scx_loader.service -b 0

FAQ

Abschnitt betitelt „FAQ“

Warum ist der X-Scheduler schlechter als der andere?

Abschnitt betitelt „Warum ist der X-Scheduler schlechter als der andere?“
  • Beim Vergleich gibt es viele Variablen zu beachten. Zum Beispiel, wie messen sie die Gewichtung einer Aufgabe? Priorisieren sie interaktive Aufgaben gegenüber nicht-interaktiven? Letztendlich hängt es von ihren Design-Entscheidungen ab.

Warum sagen alle, dass dieser X-Scheduler der beste für den Fall Y ist, er bei mir aber nicht so gut funktioniert?

Abschnitt betitelt „Warum sagen alle, dass dieser X-Scheduler der beste für den Fall Y ist, er bei mir aber nicht so gut funktioniert?“
  • Ähnlich wie bei der vorherigen Antwort können die Wahl der CPU und ihr Design, wie z. B. das Core-Layout, die gemeinsame Nutzung des Cache über die Kerne hinweg und andere damit zusammenhängende Faktoren, dazu führen, dass der Scheduler weniger effizient arbeitet.
  • Deshalb ist die Wahlmöglichkeit einer der Höhepunkte des sched-ext-Frameworks. Scheu dich also nicht, einen auszuprobieren und zu sehen, welcher für deinen Anwendungsfall am besten funktioniert. Beispiele: FPS-Stabilität, maximale Leistung, Reaktionsfähigkeit bei intensiver Arbeitslast usw.

Die Anwendungsfälle dieser Scheduler sind ziemlich ähnlich… warum ist das so?

Abschnitt betitelt „Die Anwendungsfälle dieser Scheduler sind ziemlich ähnlich… warum ist das so?“

Hauptsächlich, weil es sich um Mehrzweck-Scheduler handelt, was bedeutet, dass sie eine Vielzahl von Arbeitslasten bewältigen können, auch wenn sie vielleicht nicht in jedem Bereich überragen.

  • Um herauszufinden, welcher Scheduler am besten zu dir passt, gibt es keinen besseren Rat, als ihn selbst auszuprobieren.

Warum fehlt bei mir ein Scheduler, den einige Benutzer auf dem CachyOS-Discord-Server erwähnen oder testen?

Abschnitt betitelt „Warum fehlt bei mir ein Scheduler, den einige Benutzer auf dem CachyOS-Discord-Server erwähnen oder testen?“

Stell sicher, dass du die topaktuelle Version des scx-scheds-Pakets mit dem Namen scx-scheds-git verwendest.

  • Einer der Gründe könnte sein, dass dieser Scheduler sehr neu ist und gerade von den Benutzern getestet wird und daher noch nicht zum scx-scheds-git-Paket hinzugefügt wurde.

Warum ist der Scheduler plötzlich abgestürzt? Ist er instabil?

Abschnitt betitelt „Warum ist der Scheduler plötzlich abgestürzt? Ist er instabil?“
  • Es könnte ein paar Gründe geben, warum das passiert ist:
    • Einer der häufigsten Gründe ist, dass du ananicy-cpp neben dem Scheduler verwendet hast. Deshalb haben wir diese Warnung hinzugefügt.
    • Ein weiterer Grund könnte sein, dass die Arbeitslast, die du ausgeführt hast, die Grenzen und die Kapazität des Schedulers überschritten hat, was zu einem Stillstand führte.
      • Beispiel für eine unangemessene Arbeitslast: hackbench
    • Oder der offensichtlichere Grund: Du hast einen Bug im Scheduler gefunden. Wenn ja, melde ihn bitte als Issue in deren GitHub oder lass es sie im CachyOS-Discord-Kanal sched-ext wissen.

Ich habe den scx_loader zuvor in der Kernel-Manager-GUI verwendet. Muss ich die Übergangsschritte trotzdem befolgen?

Abschnitt betitelt „Ich habe den scx_loader zuvor in der Kernel-Manager-GUI verwendet. Muss ich die Übergangsschritte trotzdem befolgen?“
  • In diesem speziellen Fall ist es nicht notwendig, da der Kernel Manager den Übergangsprozess bereits übernimmt.
    • Es sei denn, du hast zuvor benutzerdefinierte Flags in /etc/default/scx hinzugefügt und möchtest diese weiterhin verwenden.

Mehr erfahren

Abschnitt betitelt „Mehr erfahren“