---
title: sched-ext Tutorial
description: Tutorial zur Verwendung des Frameworks und sonstige Informationen
tableOfContents:
  minHeadingLevel: 1
  maxHeadingLevel: 5
---

import { Steps, Tabs, TabItem, Icon } from '@astrojs/starlight/components';
import ImageComponent from '~/components/image-component.astro';

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.

:::note
Die Verwendung einer der sched-ext-Scheduler trennt vorübergehend den Standard-Kernel-Scheduler. Wenn ein sched-ext-Scheduler gestoppt wird, übernimmt der Standard-Kernel-Scheduler wieder.

Beispiel: EEVDF oder BORE.
:::

:::tip[Tritt mit den Entwicklern auf ihrem [Discord-Server](https://discord.gg/b2J8DrWa7t) in Kontakt]
:::

- *Die Scheduler findest du in den Paketen `scx-scheds` und `scx-scheds-git`.*
  ```sh
  # 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
  ```

  :::note
  Das `scx-scheds-git`-Paket enthält möglicherweise nicht jeden experimentellen Scheduler, da einige in separaten Feature-Branches entwickelt werden, die noch nicht in den Master-Branch gemerged wurden.
  :::

## Wie man den Scheduler startet und verwaltet

:::note
Sowohl `scxctl` als auch `scx_loader` benötigen Administratorrechte, um Scheduler zu starten/stoppen/wechseln.

Daher musst du sie mit `sudo` ausführen oder einen Polkit-Agenten verwenden, der die notwendigen Berechtigungen erteilt.

Ohne `sudo` wird scxctl/scx_loader nach einer Authentifizierung über einen Polkit-Agenten fragen.
:::

<Tabs>

<TabItem label='Terminal'>

- *Um den Scheduler zu starten, öffne dein Terminal und gib den folgenden Befehl ein:*
  ```sh title='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.

</TabItem>

<TabItem label='scxctl'>

:::note[In den Paketen `scx-tools` und `scx-tools-git` enthalten]
:::

:::caution[Benötigt einen funktionierenden Polkit-Agenten, um korrekt zu funktionieren.]
Siehe die folgende **[Arch-Wiki-Seite als Referenz.](https://wiki.archlinux.org/title/Polkit#Authentication_agents)**
:::

`scxctl` ist ein CLI-DBUS-Client zur Interaktion mit `scx_loader`.

- Features:
  - Den aktuellen Scheduler und Modus abrufen
  - Alle verfügbaren Scheduler auflisten
  - Einen Scheduler in einem bestimmten Modus oder mit bestimmten Argumenten starten
  - Zwischen Schedulern und Modi wechseln
  - Den laufenden Scheduler stoppen
  - Den laufenden Scheduler neu starten

<Tabs>
    <TabItem label='Einen Scheduler starten'>
          ```sh title='scx_flash im Gaming-Modus starten'
          scxctl start --sched flash --mode gaming
          ```
    </TabItem>
    <TabItem label='Einen Scheduler stoppen'>
          ```sh title='Den aktuell laufenden Scheduler stoppen'
          scxctl stop
          ```
    </TabItem>
    <TabItem label='Standard-Scheduler wiederherstellen'>
          ```sh title='Stellt den in der scx_loader-Konfigurationsdatei festgelegten Standard-Scheduler wieder her'
          scxctl restore
          ```
    </TabItem>
    <TabItem label='Scheduler wechseln'>
          ```sh title='Wechsel zu scx_bpfland im Gaming-Modus'
          scxctl switch --sched bpfland --mode gaming
          ```
    </TabItem>
    <TabItem label='Starten & Wechseln mit benutzerdefinierten Argumenten'>
          :::note[Füge ein Komma zwischen jedem Argument hinzu]
          Beispiel: `--args="-c,75,-m,0-15"` = Argument, Wert
          :::
          ```sh title='scx_cosmos mit benutzerdefinierten Argumenten starten'
          scxctl start --sched cosmos --args="-c,75,-m,0-15"
          ```
          ```sh title='Wechsel zu scx_flash mit benutzerdefinierten Argumenten'
          scxctl switch --sched flash --args="-s,20000"
          ```
    </TabItem>
</Tabs>

```sh
$ scxctl --help
Usage: scxctl <COMMAND>

Commands:
  get      Get the info on the running scheduler
  list     List all supported schedulers
  start    Start a scheduler in a mode or with arguments
  switch   Switch schedulers or modes, optionally with arguments
  stop     Stop the current scheduler
  restart  Restart the current scheduler with original configuration
  restore  Restore the default scheduler from configuration
  help     Print this message or the help of the given subcommand(s)

Options:
  -h, --help     Print help
  -V, --version  Print version
```

</TabItem>

<TabItem label='scx_loader (DBus)'>

:::caution[Benötigt einen funktionierenden Polkit-Agenten, um korrekt zu funktionieren.]
Siehe die folgende **[Arch-Wiki-Seite als Referenz.](https://wiki.archlinux.org/title/Polkit#Authentication_agents)**
:::

*Wie der Name schon sagt, ist es ein Dienstprogramm, das als Lader und Manager für das sched-ext-Framework über die D-Bus-Schnittstelle fungiert.*

*Obwohl es systemd nicht erfordert, kann es dennoch in Verbindung damit verwendet werden.* [Schau dir die Übergangsanleitung als Referenz an](/de/configuration/sched-ext#umstieg-von-scxservice-auf-scx_loader-eine-umfassende-anleitung).

- Hat die Fähigkeit, einen scx-Scheduler zu stoppen, zu starten, neu zu starten, Informationen darüber zu lesen und mehr.
  - *Du kannst Tools wie `dbus-send` oder `gdbus` verwenden, um damit zu kommunizieren.*
- Diese Anleitung erklärt, wie man scx_loader mit dem Befehl dbus-send verwendet.
  - ```sh title='scx_rusty mit seinen Standardargumenten starten'
    dbus-send --system --print-reply --dest=org.scx.Loader /org/scx/Loader org.scx.Loader.StartScheduler string:scx_rusty uint32:0
    ```
  - ```sh title='Einen Scheduler mit Argumenten starten'
    # Dieses Beispiel startet scx_bpfland mit den folgenden Flags: -k -c 0
    dbus-send --system --print-reply --dest=org.scx.Loader /org/scx/Loader org.scx.Loader.StartSchedulerWithArgs string:scx_bpfland array:string:"-k","-c","0"
    ```
  - ```sh title='Den aktuell laufenden Scheduler stoppen'
    dbus-send --system --print-reply --dest=org.scx.Loader /org/scx/Loader org.scx.Loader.StopScheduler
    ```
  - ```sh title='Zum Standard-Scheduler wechseln'
    # scx_loader wechselt zum Standard-Scheduler, der in der scx_loader-Konfigurationsdatei festgelegt ist
    dbus-send --system --print-reply --dest=org.scx.Loader /org/scx/Loader org.scx.Loader.RestoreDefault
    ```
  - ```sh title='Zu einem anderen Scheduler im Modus 2 wechseln'
    dbus-send --system --print-reply --dest=org.scx.Loader /org/scx/Loader org.scx.Loader.SwitchScheduler string:scx_lavd uint32:2
    # Dies wechselt zu scx_lavd mit dem Scheduler-Modus 2, was bedeutet, dass LAVD im Energiesparmodus gestartet wird
    ```
  - ```sh title='Zu einem anderen Scheduler mit Argumenten wechseln'
    dbus-send --system --print-reply --dest=org.scx.Loader /org/scx/Loader org.scx.Loader.SwitchSchedulerWithArgs string:scx_bpfland array:string:"-k","-c","0"
    ```
  - ```sh title='Den aktuell laufenden Scheduler abrufen'
    dbus-send --system --print-reply --dest=org.scx.Loader /org/scx/Loader org.freedesktop.DBus.Properties.Get string:org.scx.Loader string:CurrentScheduler
    ```
  - ```sh title='Eine Liste der unterstützten Scheduler abrufen'
    dbus-send --system --print-reply --dest=org.scx.Loader /org/scx/Loader org.freedesktop.DBus.Properties.Get string:org.scx.Loader string:SupportedSchedulers
    ```
:::tip
Hier ist eine Erklärung, was jeder Modus in scx_loader bedeutet:

- Modus 0 = `Standard-Scheduler-Flags`
- Modus 1 = `Gaming`
- Modus 2 = `Energiesparen`
- Modus 3 = `Niedrige Latenz`
- Modus 4 = `Server`

Beispiel: LAVD im Modus 1 ist das Äquivalent zu `scx_lavd --performance`

*TLDR: Jeder Modus ist ein Satz verschiedener Flags, die den beabsichtigten Anwendungsfall verbessern sollen.*

[Für einen genaueren Blick darauf, was diese Modi bei jedem Scheduler ändern](<https://github.com/sched-ext/scx-loader/blob/main/crates/scx_loader/src/config.rs#L193>)
:::

</TabItem>

<TabItem label='CachyOS Kernel Manager'>

:::caution[Benötigt einen funktionierenden Polkit-Agenten, um korrekt zu funktionieren.]
Siehe die folgende **[Arch-Wiki-Seite als Referenz.](https://wiki.archlinux.org/title/Polkit#Authentication_agents)**
:::

Du kannst darauf zugreifen und sie über den Button `sched-ext scheduler config` konfigurieren.

</TabItem>

<TabItem label='SCX Manager'>

:::caution[Benötigt einen funktionierenden Polkit-Agenten, um korrekt zu funktionieren.]
Siehe die folgende **[Arch-Wiki-Seite als Referenz.](https://wiki.archlinux.org/title/Polkit#Authentication_agents)**
:::

SCX Manager ist ein eigenständiges GUI-Tool, das vom CachyOS Kernel Manager abgeleitet ist. Es ermöglicht Benutzern, das sched-ext-Framework und seine Scheduler über `scx_loader` zu verwalten.

Features:
- Überprüfen, welcher Scheduler gerade aktiv ist
- Einen Scheduler oder ein Profil auswählen: (Auto, Gaming, Energiesparen, Niedrige Latenz oder Server)
- Zusätzliche Flags setzen
- Den aktuellen Scheduler deaktivieren

<details>
<summary>Screenshot</summary>

<ImageComponent imgsrc={import('~/assets/images/scx-manager-main.png')} />

</details>

</TabItem>

</Tabs>

## 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.

:::note
Diese Scheduler befinden sich in ständiger Entwicklung und werden getestet, erwarte also, dass sich einige ihrer Funktionen/Flags ändern können.
:::

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.

```sh title='Beispiel für Hilfe zu scx_rusty'
scx_rusty --help
```

### [scx_beerland](https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_beerland)

**Entwickelt von: Andrea Righi (arighi [GitHub](<https://github.com/arighi>))**

Produktionsreif? <Icon name="approve-check" color="var(--sl-color-text-accent)" size="2rem" />

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 funktioniert überraschend gut in bestimmten Spielen, 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

Momentan keine.

### [scx_bpfland](<https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_bpfland>)

**Entwickelt von: Andrea Righi (arighi [GitHub](<https://github.com/arighi>))**

Produktionsreif? <Icon name="approve-check" color="var(--sl-color-text-accent)" size="2rem" />

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

##### 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

* **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

* **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_cake](https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_cake)

**Entwickelt von: RitzDaCat (RitzDaCat [GitHub](<https://github.com/RitzDaCat>))**

- Produktionsreif? <Icon name="information" color="var(--sl-color-text-accent)" size="2rem" />

`scx_cake` ist ein experimenteller BPF-CPU-Scheduler, der den DRR++ (Deficit Round Robin++)-Algorithmus des Netzwerk-[CAKE](https://www.bufferbloat.net/projects/codel/wiki/Cake/)-Algorithmus für CPU-Scheduling anpasst.
- 4-Stufen-Klassifizierung - Aufgaben nach EWMA avg_runtime in Critical / Interactive / Frame / Bulk sortiert
- Keine globalen Atomics - Per-CPU-BSS-Arrays mit MESI-geschützten Schreibvorgängen eliminieren Bus-Sperrungen
- Kernel-übertragene Idle-Auswahl - scx_bpf_select_cpu_dfl() für autoritative, stale-freie CPU-Auswahl
- Per-LLC-DSQ-Sharding - Eliminiert Cross-CCD-Lock-Kontention auf Multi-Chiplet-CPUs
- DRR++ Deficit-Tracking - Der Flussfairness-Algorithmus von Netzwerk-CAKE, angepasst für die CPU-Aufgabenplanung

Entworfen für Gaming-Workloads auf moderner AMD- und Intel-Hardware.

- Anwendungsfälle:
  - Gaming

#### 4-Stufen-System

`scx_cake` klassifiziert jede Aufgabe in eine von vier Stufen basierend auf ihrer **EWMA** (Exponential Weighted Moving Average)-Laufzeit. Die Klassifizierung ist automatisch und kontinuierlich, indem sich Aufgaben zwischen den Stufen bewegen, wenn sich ihr Verhalten ändert.

##### Stufen-Grenzen

| Stufe | Name        | avg_runtime | Typischer Workload                                        | Quantum | Starvation |
| :----- | :---------- | :---------- | :------------------------------------------------------- | :------ | :--------- |
| **T0** | Critical    | < 100µs     | IRQ-Handler, Eingabetreiber, Audio (PipeWire), Netzwerk  | 0,5ms   | 3ms        |
| **T1** | Interactive | < 2ms       | Compositoren, Spiel-Physik, Spiel-KI, kurze Workers       | 2,0ms   | 8ms        |
| **T2** | Frame       | < 8ms       | Spiel-Render-Threads, Videokodierung                     | 4,0ms   | 40ms       |
| **T3** | Bulk        | ≥ 8ms       | Kompilierung, Hintergrund-Indexing, Batch-Jobs        | 8,0ms   | 100ms      |

:::tip
**Keine Spiel-Aufgabe sollte sich in T3 befinden**. Spiel-Render-Threads laufen mit 2-8ms pro Frame → T2. Physik/KI läuft mit 0,5-2ms → T1. Eingabe-Handler laufen mit < 100µs → T0. Nur Aufgaben, die 8ms+ ununterbrochene CPU-Arbeit leisten (Shader-Kompilierung, Ladebildschirme), landen in T3.
:::

##### Wie die Klassifizierung funktioniert

1. **Erstplatzierung**: Basierend auf `nice`-Wert - `nice < 0` → T0, `nice 0-10` → T1, `nice > 10` → T3
2. **Laufzeit-Autorität**: Nach ~3 Stopps wird die EWMA avg_runtime maßgeblich. Eine nice -5-Aufgabe, die 50ms-Bursts ausführt, wird unabhängig vom nice-Wert nach T3 reklassifiziert.
3. **Hysterese**: 10% deadband verhindert Oszillation an Stufengrenzen. Promotion erfordert eine avg_runtime deutlich unter der Grenze; Demotion ist sofort.
4. **Stufenweises Backoff**: Sobald eine Stufe für 3+ aufeinanderfolgende Stopps stabil ist, sinkt die Reklassifizierungsfrequenz pro Stufe: T0 überprüft alle 1024. Stopps, T3 alle 16. Instabilität setzt auf vollständige Frequenzprüfung zurück.

##### DRR++ Deficit-Tracking

Angepasst aus der Flussfairness von Netzwerk-CAKE:

- Jede Aufgabe startet mit einem **Defizit** (Quantum + new-flow-Bonus ≈ 10ms Gutschrift)
- Jeder Ausführungslauf verbraucht proportional zur Laufzeit das Defizit
- Wenn das Defizit erschöpft ist → new-flow-Bonus wird entfernt → Aufgabe konkurriert normal
- Dies gibt neu erstellten Threads (Spiel startet einen Worker) sofortige Reaktionsfähigkeit, die natürlich abklingt

##### DVFS (CPU-Frequenzskalierung)

Jede Stufe wird über eine RODATA-Lookup-Tabelle einem CPU-Leistungsziel zugeordnet:

| Stufe | Ziel               | Begründung                                             |
| :---- | :----------------- | :----------------------------------------------------- |
| T0-T2 | 100% (max. Frequenz) | Gaming-Workloads benötigen volle Leistung              |
| T3    | 75%                | Hintergrundarbeit kann etwas langsamer laufen, um Energie zu sparen |

Auf Intel-Hybrid-CPUs (`has_hybrid = true`) werden die Ziele durch die `cpuperf_cap` jedes Kerns skaliert, um eine übermäßige Anfrage von Frequenz auf E-Kernen zu verhindern.

#### Profile (`--profile, -p`)

| Profil      | Quantum | Starvation | Anwendungsfall                              |
| :---------- | :------ | :--------- | :------------------------------------------ |
| **gaming**  | 2ms     | 100ms      | **(Standard)** Ausgewogen für die meisten Spiele |
| **esports** | 1ms     | 50ms       | Wettbewerbs-FPS, ultra-niedrige Latenz       |
| **legacy**  | 4ms     | 200ms      | Ältere CPUs, Energiesparen                   |
| **default** | 2ms     | 100ms      | Alias für gaming                             |

#### CLI-Argumente

| Argument                  | Standard | Beschreibung                           |
| :------------------------ | :------- | :------------------------------------- |
| `--profile, -p <PROFILE>` | `gaming` | Voreingestelltes Profil auswählen      |
| `--quantum <µs>`          | Profil   | Basis-Time-Slice in Mikrosekunden     |
| `--new-flow-bonus <µs>`   | Profil   | Extra-Defizit für neu aufgewachte Aufgaben |
| `--starvation <µs>`       | Profil   | Maximale Laufzeit vor erzwungener Preemption |
| `--verbose, -v`           | `false`  | Live-TUI-Statistik-Anzeige aktivieren  |
| `--interval <secs>`       | `1`      | TUI-Aktualisierungsintervall           |

#### Pro-Stufe-Anpassung (Gaming-Profil)

| Stufe           | Quantum-Multiplikator | Effektive Slice | Starvation Limit |
| :------------- | :------------------- | :---------------- | :--------------- |
| T0 Critical    | 0,75x                | 1,5ms             | 3ms              |
| T1 Interactive | 1,0x                 | 2,0ms             | 8ms              |
| T2 Frame       | 1,2x                 | 2,4ms             | 40ms             |
| T3 Bulk        | 1,4x                 | 2,8ms             | 100ms            |

### [scx_cosmos](https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_cosmos)

**Entwickelt von: Andrea Righi (arighi [GitHub](<https://github.com/arighi>))**

- Produktionsreif? <Icon name="approve-check" color="var(--sl-color-text-accent)" size="2rem" />

Lightweight 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 auf Server-Workloads als auch auf Desktop-Workloads anpassen.

#### Scheduler-Modi

##### Auto

* **Kommandozeilen-Flags:** Keine.
* **Beschreibung:**

##### Gaming

* **Kommandozeilen-Flags:** `-s 700 -S`
* **Beschreibung:** Opfert Durchsatz für bessere Konsistenz in der Gaming-Leistung durch Reduzierung der Kontention auf geteilten SMT-Kernen.

##### Energiesparen

* **Kommandozeilen-Flags:** `-m powersave`
* **Beschreibung:** Priorisiert die Energieeffizienz. Bevorzugt weniger leistungsstarke Kerne (z. B. E-Kerne bei Intel).

##### Niedrige Latenz

* **Kommandozeilen-Flags:** `-s 700 -S -m performance -w`
* **Beschreibung:** Soll die Latenz auf Kosten des Durchsatzes verringern. Geeignet für Soft-Echtzeitanwendungen wie Audioverarbeitung und Multimedia. Sorgt für eine gleichmäßigere Lastverteilung über verfügbare Kerne unter Opfern der Effizienz.

##### Server

* **Kommandozeilen-Flags:** `-s 20000 -c 75 -p 250`
* **Beschreibung:** Aktiviert Adressraumaffinität, um Lokalität und Leistung bei bestimmten cache-sensitiven Workloads zu verbessern. Die Slice-Dauer ist auf 20ms eingestellt und das Polling, das überwacht, wie oft der Scheduler die CPU-Auslastung mit der CPU-Busy-Schwelle vergleicht, um zu entscheiden, wann das System ausgelastet ist.

### [scx_flash](<https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_flash>)

**Entwickelt von: Andrea Righi (arighi [GitHub](<https://github.com/arighi>))**

Produktionsreif? <Icon name="approve-check" color="var(--sl-color-text-accent)" size="2rem" />

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

Er arbeitet nach einer [Earliest Deadline First (EDF) Richtlinie](https://www.geeksforgeeks.org/operating-systems/earliest-deadline-first-edf-cpu-scheduling-algorithm/), 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

##### 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

* **Kommandozeilen-Flags:** `-m all`
* **Beschreibung:** Optimiert für hohe Leistung in Spielen.

##### 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

* **Kommandozeilen-Flags:** `-m all -s 20000 -S 1000 -I -1 -D -L`
* **Beschreibung:** Für Server-Workloads optimiert. Tauscht Reaktionsfähigkeit gegen Durchsatz.

### [scx_flow](https://github.com/sched-ext/scx/tree/main/scheds/experimental/scx_flow)

**Entwickelt von: Galih Tama (galpt [GitHub](https://github.com/galpt))**

Produktionsreif? <Icon name="approve-check" color="var(--sl-color-text-accent)" size="2rem" />

scx_flow ist ein budgetbasierter Scheduler, der Aufgaben in eine von vier O(1)-FIFO-Stufen sortiert, basierend darauf, wie viel Budget ihnen noch bleibt. Keine Heuristiken, keine Scoring-Algorithmen, keine adaptive Abstimmung, jede Entscheidung kommt aus einer Zahl: *verbleibendes Budget*.

- Anwendungsfälle:
  - Allzweck-Desktop- und Workstation-Multitasking
  - Gaming mit geöffneten Hintergrundanwendungen
  - Entwicklungsarbeit mit Builds, Tests oder Containern
  - Jedes Szenario, bei dem interaktive Reaktionsfähigkeit unter gemischter Last wichtig ist
  - Systeme, die deterministisches, erklärbares Scheduling benötigen (Eingebettete Steuerung, Robotik, Luft- und Raumfahrt)

#### Wie es funktioniert - das Budget

Stell dir vor, jede Aufgabe hat ein "Reaktions-Budget". Während eine Aufgabe schläft (auf etwas wartet), sammelt sie Budget. Wenn sie aufwacht und läuft, gibt sie es aus. Aufgaben, die aufwachen und noch Budget halten, sind ein Zeichen von Interaktivität, sie werden daher sofort zur CPU, auf der sie zuletzt liefen, verschickt und umgehen das Stufensystem vollständig. Aufgaben, die ihr Budget erschöpfen, werden in eine von vier FIFO-Stufen neu eingereiht.

##### Die vier Dispatch-Stufen

Wenn eine Aufgabe neu eingereiht wird (kein Wakeup), entscheidet ihr verbleibendes Budget, in welche Stufe sie landet:

| Stufe | Budget-Schwelle | Welche Art von Aufgaben hier landen |
|---|---|---|
| **Priority** | ≥ 1,5ms | Interaktive Aufgaben, die oft schlafen und kurz laufen |
| **Normal** | ≥ 1ms | Typische Aufgaben mit angemessenem Restbudget |
| **Low** | ≥ 0,5ms | Aufgaben, die ihr Budget fast aufgebraucht haben |
| **Deficit** | < 0,5ms | Bulk-Workers, CPU-Hogs, Hintergrundjobs |

Jede Stufe ist eine einfache FIFO-Warteschlange: O(1) Einreihung, O(1) Ausrangierung. Kein Tree-Walks, keine Prioritätsneuberechnungen.

##### Keine Starvation, keine Prioritätsinversion

Die Dispatch-Funktion entleert nicht einfach jedes Mal zuerst Priority. Sie rotiert die Startstufe bei jedem Aufruf, da `gen & 3` entscheidet, wo angefangen wird. Also wartet die Deficit-Stufe nie länger als 3 Dispatch-Zyklen, bevor sie zuerst bedient wird. Das bedeutet, dass Bulk-Workers auch unter schwerer interaktiver Last Fortschritte machen und es gibt keine Prioritätsinversion, weil keine einzelne Stufe die CPU monopolisieren kann.

##### Wakeups überspringen die Warteschlange vollständig

Wenn eine Aufgabe aufwacht (sie schlief und hat jetzt etwas zu tun), wartet sie nicht in irgendeiner Stufen-Warteschlange. Sie geht direkt über `SCX_DSQ_LOCAL_ON` zur CPU, auf der sie zuletzt lief und ist dadurch cache-warm und unmittelbar aktiv. Das ist es, was interaktive Aufgaben flott hält: ein schlafender Discord- oder Browser-Tab wacht mit Budget auf und wird in Mikrosekunden, nicht Millisekunden, verschickt.

##### Pinned-Aufgaben haben Vorrang

Aufgaben, die sich nicht zwischen CPUs bewegen können (setaffinity), bekommen ihre eigene per-CPU-FIFO-Warteschlange, die absolute Priorität vor jeder Stufe hat. Sie werden verschickt, bevor irgendetwas vom Stufensystem auf dieser CPU läuft.

##### Das Ergebnis

Interaktive Aufgaben (Tastatureingaben, UI-Updates, Audio-Threads, Netzwerk-Polling) wachen fast immer mit Budget auf und bekommen die Expressspur. CPU-lastige Batch-Arbeit (Kompilierung, Downloads, Hintergrund-Indizierung) verbraucht ihr Budget und landet in der Deficit-Stufe, wo sie dank des rotierenden Dispatch noch Fortschritte macht. Keine Abstimmung nötig.

##### Keine Profile, kein Autotuning, keine Modi

scx_flow hat **keine** Gaming-, Power-Save- oder Low-Latency-Modi und im Gegensatz zu früheren Versionen hat es auch keine adaptive Regelung. Der rotierende Stufen-Dispatch und die Budget-Schwellen sind Compile-Time-Konstanten. Was du bekommst, ist das, was läuft: deterministisch, erklärbar und auf jedem System identisch. Wenn eine Aufgabe Budget hat, bekommt sie Priorität. Wenn nicht, teilt sie die Deficit-Stufe fair. Das ist die Richtlinie dahinter.

#### Web-UI

Wenn scx_flow startet, bedient es automatisch ein Live-Metriken-Dashboard unter **[http://localhost:50005](http://localhost:50005)**. Du kannst es ohne extra Flags in jedem beliebigen Browser öffnen.

Das Dashboard zeigt:
- Wie viele Dispatches jede Stufe durchlaufen hat (Priority / Normal / Low / Deficit)
- Systeminformationen: laufende Aufgaben, Uptime, Menge der gesamten Dispatchs
- Eine Stufenverteilungsleiste, damit du auf einen Blick sehen kannst, ob interaktive oder Bulk-Arbeit dominiert
- Jede Metriken-Karte ist anklickbar - öffnet ein History-Modal mit Sparklines und einem Balkendiagramm
- Alle Werte aktualisieren sich jede Sekunde via Polling - kein Seiten-Refresh nötig

Wenn die Seite nicht lädt, hat der Scheduler möglicherweise aufgehört zu laufen (das Kernel fällt auf den eingebauten EEVDF zurück).

```sh
# Deaktiviere die Web-UI, wenn du sie nicht brauchst:
sudo scx_flow --no-webui
```

Wenn `scx_loader` mit Systemd-Hardening läuft, welches die Socket-Familien einschränkt (`RestrictAddressFamilies`, `SocketBindDeny`), ist TCP-Binding blockiert und scx_flow fällt auf einen Unix-Socket unter `/tmp/scx_flow.sock` zurück. In diesem Fall kann der Browser das Dashboard nicht direkt erreichen. Führe als temporären Fix `sudo scx_flow --no-webui` aus, um Fehler zu unterdrücken, wenn du die UI nicht brauchst.

#### CLI-Argumente

| Argument | Beschreibung |
|---|---|
| `--no-webui` | Die eingebettete Web-UI deaktivieren |
| `-d, --debug` | Debug-Level-Logging aktivieren |
| `-V, --version` | Scheduler-Version ausgeben und beenden |

:::note
scx_flow hat **keine** scx_loader-Profil-Modi (Gaming, Power Save, Low Latency, Server). Jede Scheduling-Entscheidung wird direkt aus dem Aufgaben-Budget abgeleitet, dadurch sind keine Profile nötig.
:::

### [scx_forge](<https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_forge>)

**Entwickelt von: Andrea Righi (arighi [GitHub](<https://github.com/arighi>))**

- Produktionsreif? <Icon name="close" color="var(--sl-color-text-accent)" size="2rem" />

scx_forge besteht aus zwei Teilen:

1. Ein basischer KI-orientierter Scheduler, der zusammen mit dem zweiten Teil verwendet werden soll.
2. Ein Agent, der mit dem Basis-Scheduler verwendet werden soll, um ein KI-orientierteres Scheduling-Erlebnis zu bieten, plus Optimierung vor Ort durch den Agenten selbst.

Der Agent ermöglicht das Einrichten deines KI-Modells und der Workload für die du optimieren möchtest, sowie das Gesamtziel, das du erreichen möchtest. Der Agent wird dann versuchen, den Scheduler für deine spezifische Workload und dein Ziel zu optimieren.

Wie? über die [spec.toml-Datei](https://github.com/sched-ext/scx/blob/main/tools/scx_forge_agent/spec.toml), die verwendet wird, um die Optimierungsschleife zu starten.

Im Grunde ist dieser Scheduler perfekt für diejenigen, die eine spezifische Workload durch einen KI-Agenten optimieren möchten.

Um mehr darüber zu erfahren, schau dir das [scx_forge_agent README](https://github.com/sched-ext/scx/tree/main/tools/scx_forge_agent) an.

### [scx_lavd](<https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_lavd>)

**Entwickelt von: Changwoo Min (multics69 [GitHub](<https://github.com/multics69>)).**

- Produktionsreif? <Icon name="approve-check" color="var(--sl-color-text-accent)" size="2rem" />

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

##### Gaming & Niedrige Latenz

* **Kommandozeilen-Flags:** `--performance`
* **Beschreibung:** Maximiert die Leistung durch die Nutzung aller verfügbaren Kerne und priorisiert physische Kerne.

##### Energiesparen

* **Kommandozeilen-Flags:** `--powersave`
* **Beschreibung:** Minimiert den Stromverbrauch bei angemessener Leistung. Priorisiert effiziente Kerne und Threads gegenüber physischen Kernen.

### [scx_pandemonium](https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_pandemonium)

**Entwickelt von: Will Clingan (willclngn [GitHub](https://github.com/wllclngn/))**

*Ein verhaltensbasiert-klassifizierender Scheduler mit topologiebewusster Platzierung. EWMA-gesteuerte Bewertung (Wakeup-Frequenz, Kontextwechsel-Rate, Laufzeitvarianz) sortiert Aufgaben in drei Stufen, LAT_CRITICAL, INTERACTIVE und BATCH, jede mit ihrer eigenen Slice, Preempt-Regeln und DSQ-Routing. Die Platzierung wird durch effektiven Widerstand (R_eff) im CPU-Topologiegraphen gesteuert, abgeleitet aus einer Laplace-Pseudoinversen; per-CPU-DSQs werden in R_eff-Reihenfolge gestohlen, um cache-hot-Arbeit cache-hot zu halten. Jede Zeitkonstante, Sojourn-Rescue, CoDel-Ziel, vtime-Obergrenze und longrun-Schwelle, leitet sich von einem einzigen tau-Wert (dem Fiedler eigenvalue's reciprocal) ab, sodass sich der Scheduler von 2C-Laptops bis 32C+-Servern ohne Abstimmung selbst kalibriert. Ein gedämpfter harmonischer Oszillator passt das CoDel-Stall-Ziel von Rescue-Druck jeden Takt an. Eine 1Hz-Rust-adaptive Regelung (multiplikatives Gewichts-Update über sechs Expertenprofile) stimmt Scheduling-Parameter von BPF-Histogramm-Telemetrie ab und synchronisiert mit dem BPF-Oszillator-Zustand, um Doppelkorrektur zu vermeiden. Eine persistente Prozessdatenbank lernt Aufgabenklassifizierungen über Neustarts hinweg. NUMA-aware, hotplug-correct.*

- Anwendungsfälle:
    - Gaming
    - Desktop-Nutzung
    - Multimedia-/Audio-Produktion
    - Codebase-Kompilierung
    - ZFS / storage-lastige Workloads
    - Gemischte Workloads
    - Interaktivität unter anhaltender CPU-Auslastung

##### Scheduler-Modi
Standard (Adaptiv)
- **Kommandozeilen-Flags:** (keine, läuft adaptiv standardmäßig)
- **Beschreibung:** Vollständiger adaptiver Modus. Die Rust-Regelung erkennt das Workload-Regime (LIGHT / MIXED / HEAVY) und passt Scheduling-Parameter in Echtzeit an. Am besten für allgemeine Desktop-Nutzung und Gaming geeignet.

###### BPF Only
- **Kommandozeilen-Flags:** `--no-adaptive`
- **Beschreibung:** Deaktiviert die Rust-adaptive Regelung. Der BPF-Scheduler läuft mit statischen Abstimmungsparametern. Geringerer Overhead, nützlich für Benchmarking oder wenn die adaptive Schicht bei deiner Workload überkorrigiert.

###### Verbose / Debug
- **Kommandozeilen-Flags:** `-v` oder `--verbose`
- **Beschreibung:** Aktiviert detaillierte Telemetrie-Ausgabe einschließlich pro-Stufe-Dispatch-Zählungen, Sojourn-Zeiten und verhaltensbasiert-klassifizierender Statistiken. Nützlich zur Diagnose des Scheduling-Verhaltens.


### [scx_p2dq](<https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_p2dq>)

- Produktionsreif? <Icon name="information" color="var(--sl-color-text-accent)" size="2rem" />
  - Ja. Wenn er für deinen spezifischen Workload und deine Hardware richtig eingestellt ist.

**Entwickelt von: Daniel Hodges (hodgesds [GitHub](<https://github.com/hodgesds>))**

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

##### 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)

* **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)

* **Kommandozeilen-Flags:** `--sched-mode efficiency`
* **Beschreibung:** Verbessert die Energieeffizienz, indem energieeffiziente Kerne bevorzugt werden.

##### 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](<https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_tickless>)

**Entwickelt von: Andrea Righi (arighi [Github](<https://github.com/arighi>))**

- Für den Produktionseinsatz bereit? <Icon name="close" color="var(--sl-color-text-accent)" size="2rem" />
  - Dieser Scheduler ist noch experimentell und wird nicht für den produktiven Einsatz empfohlen.

:::note
Um die "Ticks" auf den "tickless"-CPUs effektiv zu deaktivieren, muss der Kernel mit `nohz_full` gebootet werden. Denk dran, dass `nohz_full` einen Mehraufwand bei Systemaufrufen (Syscalls) verursacht, was bei latenzempfindlichen Workloads zu Leistungseinbußen führen kann.
:::

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

##### 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)

* **Kommandozeilen-Flags:** `-f 50`
* **Beschreibung:** Verbessert die Energieeffizienz, indem die Überprüfung auf Konflikte seltener stattfindet.

##### Low Latency (Geringe Latenz)
* **Kommandozeilen-Flags:** `-f 5000 -s 1000`
* **Beschreibung:** Ähnlich wie das Gaming-Profil, aber mit einer noch kürzeren "Slice".

##### 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.

### [scx_rustland](<https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_rustland>)

**Entwickelt von: Andrea Righi (arighi [GitHub](<https://github.com/arighi>))**

Produktionsreif? <Icon name="information" color="var(--sl-color-text-accent)" size="2rem" />

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.

Hat Ä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 eine leichte Durchsatzeinbuße gibt, wenn ein Userspace-Scheduler verwendet wird.

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

### [scx_rusty](<https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_rusty>)

**Entwickelt von: David Vernet (Byte-Lab [GitHub](<https://github.com/Byte-Lab>))**

- Produktionsreif? <Icon name="information" color="var(--sl-color-text-accent)" size="2rem" />
  - 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 Anpassbarkeit, 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

## Konfiguration und Leistungstests

### 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).

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

### ananicy-cpp & sched-ext

:::note[Update zu ananicy-cpp und sched-ext]
Nach weiterer Entwicklung der Scheduler ist es normalerweise in Ordnung, ananicy-cpp zusammen mit ihnen zu verwenden. Wenn du jedoch Hänger oder Instabilität feststellst, solltest du es als einen Schritt zur Fehlerbehebung deaktivieren.
:::

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

```sh
systemctl disable --now ananicy-cpp
```

### scx_loader Power Profile Switching

Im Paket `power-profiles-daemon` von CachyOS implementiert, das einen [benutzerdefinierten Patch](https://github.com/CachyOS/CachyOS-PKGBUILDS/blob/master/power-profiles-daemon/0001-Add-support-for-scx_loader-modes-switching.patch) enthält, um `scx_loader` Power-Profile-Umschaltung zu unterstützen.

- Wenn `scx_loader` gerade läuft und [game-performance](/de/configuration/gaming#wechsel-des-leistungsprofils-bei-bedarf) verwendet wird, schaltet es automatisch den aktiven Scheduler auf das `Gaming`-Profil um, wenn ein Spiel gestartet wird und kehrt zum Standardprofil zurück, wenn das Spiel geschlossen wird.
- Beim Wechseln zwischen Energieprofilen, z. B. in KDE Plasma oder GNOME über den Energieprofil-Umschalter, schaltet `scx_loader` automatisch zum entsprechenden Scheduler-Profil um:

| Power Profil       | Scheduler Profil  |
| ------------------- | ------------------ |
| Power Saver         | Power Save         |
| Balanced            | Auto               |
| Performance         | Gaming             |

### Benchmarking und Vergleich von Schedulern mit dem cachyos-benchmarker

Das Tool [cachyos-benchmarker](https://github.com/CachyOS/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:

| Test                        | Misst                                 | Tool         |
| --------------------------- | -------------------------------------- | ------------ |
| **stress-ng cpu-cache-mem** | CPU-, Cache- und Speicherleistung      | `stress-ng`  |
| **FFmpeg-Kompilierung**     | Parallele Build-Leistung               | `make`       |
| **x265-Kodierung**          | Videokodierungs-Durchsatz              | `x265`       |
| **argon2-Hashing**          | Multithreaded-Passwort-Hashing         | `argon2`     |
| **perf sched msg**          | Kontextwechsel- und IPC-Leistung       | `perf`       |
| **perf memcpy**             | Speicherdurchsatz `memcpy()`           | `perf`       |
| **Primzahlberechnung**      | Ganzzahl-Arithmetik und Parallelität   | `primesieve` |
| **NAMD**                    | Molekulardynamik (wissenschaftliche Arbeitslast) | `namd3`      |
| **Blender-Render**          | Reines CPU-3D-Rendering                | `blender`    |
| **xz-Kompression**          | Kompressionsdurchsatz                  | `xz`         |
| **Kernel-defconfig-Build**  | Kernel-Kompilierungsleistung           | `make`       |
| **y-cruncher**              | Mathematische Präzision und Speicherbelastung | `y-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:
  ```bash
  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
- 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

Um `cachyos-benchmarker` zu installieren, führe den folgenden Befehl aus:
```bash
sudo pacman -S cachyos-benchmarker
```

#### Ausführen des Benchmarks

<Steps>
    1. Führe `cachyos-benchmarker` aus:
        ```bash
        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.
                <details>
                <summary>Beispiel für die Terminal-Ausgabe:</summary>
                ```text
                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
                ```
                </details>
                <details>
                <summary>HTML-Beispiel eines Testergebnisses, das zwei verschiedene Branches desselben Schedulers vergleicht:</summary>
                <ImageComponent imgsrc={import('~/assets/images/cachyos-benchmarker-example.png')} />
                </details>
    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.
</Steps>

### 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

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

`schbench` ist in den CachyOS-Repositories verfügbar:
```bash
sudo pacman -S schbench
```

#### Ausführen des Benchmarks

Eine einfache Möglichkeit, `schbench` für einen allgemeinen Latenztest auszuführen, ist:
```bash
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:

| Option                       | Beschreibung                                                     |
| ---------------------------- | --------------------------------------------------------------- |
| `-C, --calibrate`            | Kalibrierung durchführen und Zeitmessung berichten (kein Benchmark). |
| `-L, --no-locking`           | Spinlocks 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-rps`             | RPS 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

Nach jedem Durchlauf gibt `schbench` Latenzperzentile aus, wie hier:

<details>
    <summary>Beispiel für die Ausgabe</summary>
    ```bash
    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
    ```
</details>

##### 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.

:::note
Diese Ergebnisse können je nach CPU, Kernanzahl, Systemlast und der Fähigkeit des Schedulers, deine CPU-Architektur effizient zu handhaben, variieren.
:::

### 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](https://www.pcgamingwiki.com/wiki/List_of_games_with_built-in_benchmarks) 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](/de/configuration/sched-ext#wie-man-den-scheduler-startet-und-verwaltet) oder durch das Erstellen eigener Skripte erfolgen, die den aktiven Scheduler und seinen Modus ändern.

#### Hochladen und Teilen deiner Benchmarks

Diese [Website](https://flightlesssomething.ambrosia.one/benchmarks) 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.

## scx_loader-Konfiguration

### Einen Scheduler als Standard festlegen (beim Booten)

Um einen Scheduler so einzurichten, dass er automatisch gestartet wird, wenn `scx_loader` startet (z. B. beim Booten), folge diesen Schritten:

<Steps>
1. **Kopiere die Beispiel-Konfigurationsdatei** in das Konfigurationsverzeichnis:
   ```sh
   sudo mkdir -p /etc/scx_loader
   sudo cp /usr/share/scx_loader/config.toml /etc/scx_loader/config.toml
   ```

2. **Bearbeite die Konfigurationsdatei** mit deinem bevorzugten Editor:
   ```sh
   sudo nano /etc/scx_loader/config.toml
   ```

3. **Setze den Standard-Scheduler und den Modus**. Zum Beispiel, um `scx_pandemonium` im `Auto`-Modus zu setzen:
   ```toml
   # Dieses Feld gibt den Scheduler an, der automatisch gestartet wird, wenn scx_loader startet (z. B. beim Booten).
   default_sched = "scx_pandemonium"

   # Dieses Feld gibt den Modus an, der verwendet wird, wenn scx_loader startet (z. B. beim Booten).
   default_mode = "Auto"
   ```

4. **Aktiviere und starte den Dienst**:
   ```sh
   sudo systemctl enable --now scx_loader.service
   ```
</Steps>

#### Konfigurations-Suchreihenfolge

`scx_loader` sucht nach der Konfigurationsdatei in folgender Reihenfolge:

1. `/etc/scx_loader/config.toml` (Bevorzugt)
2. `/etc/scx_loader.toml`
3. `/usr/share/scx_loader/config.toml` (Standard-Vorlage)
4. `/usr/share/scx_loader.toml`

### Anpassen von Scheduler-Argumenten

Du kannst die an jeden Scheduler für verschiedene Modi übergebenen Argumente anpassen, indem du einen `[scheds.scx_name]`-Abschnitt zu deiner Konfigurationsdatei hinzufügst.

Für detaillierte Informationen und Beispiele zur Konfiguration von pro-Scheduler-Argumenten, siehe die [scx_loader-Konfigurationsdokumentation](https://github.com/sched-ext/scx-loader/blob/main/crates/scx_loader/configuration.md).

## Umstieg von scx.service auf scx_loader: Eine umfassende Anleitung

:::caution
Versuche nicht, den scx_loader.service zusammen mit dem scx.service auszuführen, sonst startet der Loader-Service zwar, tut aber nichts.

Dieser Konflikt entsteht, weil beide Dienste nichts voneinander wissen, insbesondere nicht, welcher von ihnen die Scheduler verwaltet.
:::

:::tip
Der CachyOS Kernel Manager enthält bereits eine [GUI zur Verwaltung des scx_loader.](/de/features/kernel_manager#sched-ext-framework-management)
:::

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:*

```sh title='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:

```sh title='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](https://github.com/sched-ext/scx-loader/blob/main/crates/scx_loader/configuration.md#scx_loader-configuration-file)

Folge der nachstehenden Anleitung für einen einfachen Übergang vom `scx systemd service` zum neuen `scx_loader`-Dienstprogramm.
<Steps>
  1. ```sh title='Deaktivieren von scx.service zugunsten des scx_loader.service'
      systemctl disable --now scx.service && systemctl enable --now scx_loader.service
      ```
  2. ```sh title='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. ```sh title='Neustarten des scx_loader'
     systemctl restart scx_loader.service
     ```
     - Du bist fertig, der scx_loader wird nun den gewünschten Scheduler laden und starten.

  </Steps>

### Debugging im scx_loader

<Tabs>
<TabItem label='Einfaches Logging'>

  - ```sh title='Dienststatus überprüfen'
    systemctl status scx_loader.service
    ```
  - ```sh title='Alle Log-Einträge des Dienstes anzeigen'
    journalctl -u scx_loader.service
    ```
  - ```sh title='Nur die Logs der aktuellen Sitzung anzeigen.'
    journalctl -u scx_loader.service -b 0
    ```
</TabItem>
<TabItem label='Erweitertes Logging'>

*Um ein detaillierteres Log zu erhalten, befolge diese Schritte.*
  - ```sh title='Die Service-Datei bearbeiten'
     sudo systemctl edit scx_loader.service
     ```
  - ```sh title='Füge die folgende Zeile unter dem Abschnitt [Service] hinzu'
     Environment=RUST_LOG=trace
     ```
  - ```sh title='Den Dienst neu starten'
     sudo systemctl restart scx_loader.service
     ```
  - Überprüfe die Logs erneut, um detailliertere Debugging-Informationen zu erhalten.
</TabItem>

</Tabs>

## FAQ

### Es gibt so viele Optionen... warum macht man nicht einfach einen Scheduler, der in allem gut ist?

Der Hauptgrund ist, dass es bei der CPU-Scheduling keine One-Size-Fits-All-Lösung gibt. Unterschiedliche Workloads haben unterschiedliche Anforderungen und Prioritäten und ein für eine Art von Workload optimierter Scheduler funktioniert möglicherweise nicht gut für eine andere.

Du kannst CPU-Scheduler wie verschiedene Paar Schuhe betrachten, jedes für eine bestimmte Aktivität konzipiert. Ein Spiel auf einem für Server-Workloads optimierten Scheduler auszuführen, kann zu suboptimaler Leistung und erhöhter Latenz führen, während ein für Gaming konzipierter Scheduler auf einem Server zu ineffizienter Ressourcennutzung und reduziertem Durchsatz führen kann.

Das ist die Magie von sched-ext. Einschränkungen sind kein Problem mehr.

### Warum funktioniert der Scheduler X schlechter als Y?

- 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 Scheduler X der beste für Y ist, aber bei mir funktioniert er nicht gut?

- 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?

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?
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?

- *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](/de/configuration/sched-ext#ananicy-cpp--sched-ext) 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](https://github.com/sched-ext/scx/issues) 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?

- 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

:::note[Danksagung]
Einige der folgenden Links wurden ursprünglich aus dem [sched-ext GitHub-Repository](https://github.com/sched-ext/scx?tab=readme-ov-file#sched_ext-schedulers-and-tools) übernommen.
Voller Dank gebührt den Maintainern und Mitwirkenden von sched-ext für das Kuratieren und Teilen dieser exzellenten Ressourcen.
:::

- [Sched_ext YT-Playlist](https://youtube.com/playlist?list=PLLLT4NxU7U1TnhgFH6k57iKjRu6CXJ3yB&si=DETiqpfwMoj8Anvl)
- [LWN: The extensible scheduler class (Februar 2023)](https://lwn.net/Articles/922405/)
- [arighis Blog: Implement your own kernel CPU scheduler in Ubuntu with sched_ext (Juli 2023)](https://arighi.blogspot.com/2023/07/implement-your-own-cpu-scheduler-in.html)
- [David Vernets Vortrag: Kernel Recipes 2023 - sched_ext: pluggable scheduling in the Linux kernel (September 2023)](https://youtu.be/8kAcnNVSAdI?si=F5Q-dkSS_sG9BTXA)
- [Changwoos Blog: sched_ext: a BPF-extensible scheduler class (Part 1) (Dezember 2023)](https://blogs.igalia.com/changwoo/sched-ext-a-bpf-extensible-scheduler-class-part-1/)
- [arighis Blog: Getting started with sched_ext development (April 2024)](https://arighi.blogspot.com/2024/04/getting-started-with-sched-ext.html)
- [Changwoos Blog: sched_ext: scheduler architecture and interfaces (Part 2) (Juni 2024)](https://blogs.igalia.com/changwoo/sched-ext-scheduler-architecture-and-interfaces-part-2/)
- [arighis YT-Kanal: scx_bpfland Linux scheduler demo: topology awareness (August 2024)](https://youtu.be/R-FEZOveG-I)
- [David Vernets Vortrag: Kernel Recipes 2024 - Scheduling with superpowers: Using sched_ext to get big perf gains (September 2024)](https://youtu.be/Cy7-oqdcUCs?si=bjKu3uidOdIzzAWv)
