---
title: Tutorial de sched-ext
description: Tutorial sobre cómo usar el framework e información variada
tableOfContents:
  minHeadingLevel: 1
  maxHeadingLevel: 5
ai_translated: true
---

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

La Clase de Planificador Extensible (más conocida como `sched-ext`) es una característica del kernel de Linux que permite implementar planificadores de hilos del kernel en
BPF (Berkeley Packet Filter) y cargarlos dinámicamente. Esencialmente, esto permite a los usuarios finales cambiar sus planificadores en el espacio de usuario sin
la necesidad de compilar otro kernel solo para tener un planificador diferente.

:::note
El uso de cualquier planificador sched-ext desvinculará temporalmente el planificador por defecto del kernel. Cuando se detenga un planificador sched-ext, el planificador por defecto del kernel retomará el control.

Ejemplo: EEVDF o BORE.
:::

:::tip[Ponte en contacto con los desarrolladores en su [servidor de Discord](https://discord.gg/b2J8DrWa7t)]
:::

- *Los planificadores se pueden encontrar en los paquetes `scx-scheds` y `scx-scheds-git`.*
  ```sh
  # Rama estable + herramientas scx_loader y scxctl.
  sudo pacman -S scx-scheds scx-tools

  # Rama de vanguardia (esta rama incluye los últimos cambios de la rama master.) + herramientas scx_loader y scxctl.
  sudo pacman -S scx-scheds-git scx-tools-git
  ```

  :::note
  El paquete `scx-scheds-git` puede no incluir todos los planificadores experimentales, ya que algunos se desarrollan en ramas de características separadas que aún no se han fusionado en la rama master.
  :::

## Cómo Lanzar y Gestionar el Planificador

:::note
Tanto `scxctl` como `scx_loader` requieren privilegios administrativos para iniciar/detener/cambiar planificadores.

Por lo tanto, necesitarás ejecutarlos con `sudo` o usando un agente de polkit que otorgue los permisos necesarios.

Sin `sudo`, scxctl/scx_loader pedirá autenticación a través de un agente de polkit.
:::

<Tabs>

<TabItem label='Terminal'>

- *Para iniciar el planificador, abre tu terminal e introduce el siguiente comando:*
  ```sh title='Ejemplo de cómo iniciar rusty'
  sudo scx_rusty
  ```

*Esto lanzará el planificador rusty y desvinculará el planificador por defecto.*

Para detener el planificador. Presiona `CTRL + C` y el planificador se detendrá y el planificador por defecto del kernel retomará el control.

</TabItem>

<TabItem label='scxctl'>

:::note[Incluido en los paquetes `scx-tools` y `scx-tools-git`]
:::

:::caution[Requiere un agente de polkit funcional para operar correctamente.]
Consulta la siguiente **[página de la Arch Wiki como referencia.](https://wiki.archlinux.org/title/Polkit#Authentication_agents)**
:::

`scxctl` es un cliente CLI de DBUS para interactuar con `scx_loader`.

- Características:
  - Obtener el planificador y modo actual
  - Listar todos los planificadores disponibles
  - Iniciar un planificador en un modo dado, o con argumentos dados
  - Cambiar entre planificadores y modos
  - Detener el planificador en ejecución
  - Reiniciar el planificador en ejecución

<Tabs>
    <TabItem label='Iniciando un planificador'>
          ```sh title='Iniciando scx_flash en modo Gaming'
          scxctl start --sched flash --mode gaming
          ```
    </TabItem>
    <TabItem label='Deteniendo un planificador'>
          ```sh title='Deteniendo el planificador actualmente en ejecución'
          scxctl stop
          ```
    </TabItem>
    <TabItem label='Restaurar planificador por defecto'>
          ```sh title='Restaura el planificador por defecto establecido en el archivo de configuración de scx_loader'
          scxctl restore
          ```
    </TabItem>
    <TabItem label='Cambiando de planificador'>
          ```sh title='Cambiando a scx_bpfland en modo Gaming'
          scxctl switch --sched bpfland --mode gaming
          ```
    </TabItem>
    <TabItem label='Iniciando y Cambiando con argumentos personalizados'>
          :::note[Añade una coma entre cada argumento]
          Ejemplo: `--args="-c,75,-m,0-15"` = Argumento, Valor
          :::
          ```sh title='Iniciando scx_cosmos con argumentos personalizados'
          scxctl start --sched cosmos --args="-c,75,-m,0-15"
          ```
          ```sh title='Cambiando a scx_flash con argumentos personalizados'
          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[Requiere un agente de polkit funcional para operar correctamente.]
Consulta la siguiente **[página de la Arch Wiki como referencia.](https://wiki.archlinux.org/title/Polkit#Authentication_agents)**
:::

*Como su nombre indica, es una utilidad que funciona como cargador y gestor para el framework sched-ext usando la interfaz D-Bus.*

*Aunque no requiere systemd, puede utilizarse junto con él.* [Consulta la guía de transición como referencia](/es/configuration/sched-ext#transicion-de-scxservice-a-scx_loader-una-guia-completa).

- Tiene la capacidad de detener, iniciar, reiniciar, leer información sobre un planificador scx y más.
  - *Puedes usar herramientas como `dbus-send` o `gdbus` para comunicarte con él.*
- Esta guía explica cómo usar scx_loader con el comando dbus-send.
  - ```sh title='Iniciando scx_rusty con sus argumentos por defecto'
    dbus-send --system --print-reply --dest=org.scx.Loader /org/scx/Loader org.scx.Loader.StartScheduler string:scx_rusty uint32:0
    ```
  - ```sh title='Iniciando un planificador con argumentos'
    # Este ejemplo inicia scx_bpfland con las siguientes 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='Deteniendo el planificador actualmente en ejecución'
    dbus-send --system --print-reply --dest=org.scx.Loader /org/scx/Loader org.scx.Loader.StopScheduler
    ```
  - ```sh title='Cambiar al planificador por defecto'
    # scx_loader cambiará al planificador por defecto establecido en el archivo de configuración de scx_loader
    dbus-send --system --print-reply --dest=org.scx.Loader /org/scx/Loader org.scx.Loader.RestoreDefault
    ```
  - ```sh title='Cambiando a otro planificador en Modo 2'
    dbus-send --system --print-reply --dest=org.scx.Loader /org/scx/Loader org.scx.Loader.SwitchScheduler string:scx_lavd uint32:2
    # Esto cambia a scx_lavd con el modo de planificador 2, lo que significa que inicia LAVD en modo de ahorro de energía
    ```
  - ```sh title='Cambiando a otro planificador con argumentos'
    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='Obteniendo el planificador actualmente en ejecución'
    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='Obteniendo una lista de los planificadores soportados'
    dbus-send --system --print-reply --dest=org.scx.Loader /org/scx/Loader org.freedesktop.DBus.Properties.Get string:org.scx.Loader string:SupportedSchedulers
    ```
:::tip
Aquí hay una explicación de lo que significa cada modo en scx_loader:

- Modo 0 = `Flags del planificador por defecto`
- Modo 1 = `Gaming`
- Modo 2 = `Ahorro de energía`
- Modo 3 = `Baja latencia`
- Modo 4 = `Servidor`

Ejemplo: LAVD ejecutándose en Modo 1 es el equivalente a `scx_lavd --performance`

*En resumen: cada modo es un conjunto de diferentes flags destinados a mejorar el caso de uso previsto.*

[Para una visión más detallada de lo que estos Modos cambian en cada planificador](<https://github.com/sched-ext/scx-loader/blob/main/crates/scx_loader/src/config.rs#L193>)
:::

</TabItem>

<TabItem label='CachyOS Kernel Manager'>

:::caution[Requiere un agente de polkit funcional para operar correctamente.]
Consulta la siguiente **[página de la Arch Wiki como referencia.](https://wiki.archlinux.org/title/Polkit#Authentication_agents)**
:::

Puedes acceder y configurarlos a través del botón `sched-ext scheduler config`.

</TabItem>

<TabItem label='SCX Manager'>

:::caution[Requiere un agente de polkit funcional para operar correctamente.]
Consulta la siguiente **[página de la Arch Wiki como referencia.](https://wiki.archlinux.org/title/Polkit#Authentication_agents)**
:::

SCX Manager es una herramienta gráfica independiente derivada del CachyOS Kernel Manager. Permite a los usuarios gestionar el framework sched-ext y sus planificadores a través de `scx_loader`.

Características:
- Comprobar qué planificador está activo actualmente
- Seleccionar un planificador o perfil: (Auto, Gaming, Ahorro de energía, Baja latencia o Servidor)
- Establecer flags adicionales
- Deshabilitar el planificador actual

<details>
<summary>Captura de pantalla</summary>

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

</details>

</TabItem>

</Tabs>

## Guía de Planificadores: Perfiles y Casos de Uso

Dado que hay muchos planificadores para elegir, queremos dar una pequeña introducción sobre los planificadores disponibles.

:::note
Estos planificadores están en constante desarrollo mientras se prueban, así que espera que algunas de sus características/flags puedan cambiar.
:::

No dudes en reportar cualquier problema o dar tu opinión en el repositorio de cada planificador.

Usa `scx_nombredelplanificador --help` para ver las flags disponibles y una breve descripción de lo que hacen.

```sh title='Ejemplo de cómo obtener ayuda para scx_rusty'
scx_rusty --help
```

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

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

¿Listo para producción? <Icon name="approve-check" color="var(--sl-color-text-accent)" size="2rem" />

scx_beerland es un planificador diseñado para priorizar la localidad y la escalabilidad.

Prioriza mantener las tareas en la misma CPU para conservar la localidad de la caché, al mismo tiempo que asegura una buena escalabilidad en muchos CPUs mediante el uso de DSQs locales (colas de ejecución por CPU) cuando el sistema no está saturado.

- Casos de uso:
  - Cargas de trabajo intensivas en caché
  - Sistemas con una gran cantidad de CPUs
  - Videojuegos: Funciona sorprendentemente bien en ciertos juegos, aunque los resultados pueden variar.
  - Servidor: Bueno para cargas de trabajo de servidor de propósito general debido a sus optimizaciones de escalabilidad y localidad.
  - También se puede usar para escritorio.

#### Modos del Planificador

Ninguno por el momento.

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

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

¿Listo para producción? <Icon name="approve-check" color="var(--sl-color-text-accent)" size="2rem" />

Un planificador de sched_ext basado en vruntime que prioriza las cargas de trabajo interactivas. Altamente flexible y fácil de adaptar.

Al tomar decisiones sobre qué núcleos usar, Bpfland tiene en cuenta su diseño de caché y qué núcleos comparten la misma caché L2/L3, lo que resulta en menos fallos de caché = más rendimiento.

- Casos de uso:
  - Videojuegos
  - Uso de escritorio
  - Producción multimedia/audio
  - Gran interactividad bajo cargas de trabajo intensivas
  - Ahorro de energía
  - Servidor

#### Modos del Planificador

##### Baja Latencia

* **Flags de línea de comandos:** `-m performance -w`
* **Descripción:** Diseñado para reducir la latencia a costa del throughput. Adecuado para aplicaciones de tiempo real flexible como el procesamiento de audio y multimedia.

##### Ahorro de Energía

* **Flags de línea de comandos:** `-s 20000 -m powersave -I 100 -t 100`
* **Descripción:** Prioriza la eficiencia energética. Favorece los núcleos menos potentes (por ejemplo, los E-cores en Intel).

##### Servidor

* **Flags de línea de comandos:** `-s 20000 -S`
* **Descripción:** Prioriza tareas con afinidad estricta. Esta opción puede aumentar el throughput a costa de la latencia y es más adecuada para cargas de trabajo de servidor.

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

**Desarrollado por: RitzDaCat (RitzDaCat [GitHub](<https://github.com/RitzDaCat>))**

- ¿Listo para producción? <Icon name="information" color="var(--sl-color-text-accent)" size="2rem" />

`scx_cake` es un planificador de CPU BPF experimental que adapta el algoritmo DRR++ (Deficit Round Robin++) de la red [CAKE](https://www.bufferbloat.net/projects/codel/wiki/Cake/) para la planificación de la CPU.
- Clasificación de 4 niveles — Tareas ordenadas por avg_runtime EWMA en Crítico / Interactivo / Frame / Bulk
- Sin atómicos globales — Matrices BSS por CPU con escrituras protegidas por MESI eliminan el bloqueo de bus
- Selección de reposo delegada al kernel — scx_bpf_select_cpu_dfl() para selección de CPU autoritativa y sin datos obsoletos
- Fragmentación de DSQ por LLC — Elimina la contención de bloqueo entre CCD en CPUs multi-chiplet
- Seguimiento de déficit DRR++ — Algoritmo de equidad de flujo de la red CAKE adaptado para la planificación de tareas de la CPU

Diseñado para cargas de trabajo de videojuegos en hardware moderno de AMD e Intel.

- Casos de uso:
  - Videojuegos

#### Sistema de 4 Niveles

`scx_cake` clasifica cada tarea en uno de cuatro niveles según su tiempo de ejecución **EWMA** (Exponential Weighted Moving Average). La clasificación es automática y continua — las tareas se mueven entre niveles a medida que cambia su comportamiento.

##### Umbrales de Nivel

| Nivel   | Nombre        | avg_runtime | Carga de Trabajo Típica                                       | Quantum | Privación |
| :----- | :---------- | :---------- | :----------------------------------------------------- | :------ | :--------- |
| **T0** | Crítico    | < 100µs     | Manejadores IRQ, controladores de entrada, audio (PipeWire), red | 0.5ms   | 3ms        |
| **T1** | Interactivo | < 2ms       | Compositores, física de juegos, IA de juegos, workers cortos      | 2.0ms   | 8ms        |
| **T2** | Frame       | < 8ms       | Hilos de renderizado de juegos, codificación de video                    | 4.0ms   | 40ms       |
| **T3** | Bulk        | ≥ 8ms       | Compilación, indexación en segundo plano, trabajos por lotes           | 8.0ms   | 100ms      |

:::tip
**Ninguna tarea de juego debería estar en T3**. Los hilos de renderizado de juegos ejecutan 2-8ms por frame → T2. Física/IA ejecutan 0.5-2ms → T1. Manejadores de entrada ejecutan < 100µs → T0. Solo las tareas que realizan 8ms+ de trabajo de CPU ininterrumpido (compilación de shaders, pantallas de carga) aterrizan en T3.
:::

##### Cómo Funciona la Clasificación

1. **Colocación inicial:** Basada en el valor `nice` — `nice < 0` → T0, `nice 0-10` → T1, `nice > 10` → T3
2. **Autoridad de tiempo de ejecución:** Después de ~3 paradas, el avg_runtime EWMA se vuelve autoritativo. Una tarea nice -5 que ejecuta ráfagas de 50ms se reclasificará a T3 independientemente del valor nice.
3. **Histéresis:** Un margen muerto del 10% evita oscilaciones en los límites de nivel. La promoción requiere avg_runtime claramente por debajo del umbral; la degradación es inmediata.
4. **Retroceso gradual:** Una vez que un nivel es estable durante 3+ paradas consecutivas, la frecuencia de reclasificación disminuye por nivel: T0 vuelve a verificar cada 1024ª parada, T3 cada 16ª. La inestabilidad se restablece a verificación a frecuencia completa.

##### Seguimiento de Déficit DRR++

Adaptado de la equidad de flujo de la red CAKE:

- Cada tarea comienza con un **déficit** (quantum + bono de nuevo flujo ≈ 10ms de crédito)
- Cada ejecución consume déficit proporcional al tiempo de ejecución
- Cuando el déficit se agota → se elimina el bono de nuevo flujo → la tarea compite normalmente
- Esto da a los hilos recién creados (un juego que lanza un worker) capacidad de respuesta instantánea que decae naturalmente

##### DVFS (Escalado de Frecuencia de CPU)

Cada nivel se mapea a un objetivo de rendimiento de CPU a través de una tabla de búsqueda RODATA:

| Nivel  | Objetivo               | Razón                                             |
| :---- | :------------------- | :---------------------------------------------------- |
| T0-T2 | 100% (frecuencia máxima) | Las cargas de trabajo de juegos necesitan rendimiento completo                |
| T3    | 75%                  | El trabajo en segundo plano puede ejecutarse un poco más lento para ahorrar energía |

En CPUs híbridas de Intel (`has_hybrid = true`), los objetivos se escalan según el `cpuperf_cap` de cada núcleo para evitar solicitar demasiada frecuencia en los E-cores.

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

| Perfil     | Quantum | Privación | Caso de Uso                              |
| :---------- | :------ | :--------- | :------------------------------------ |
| **gaming**  | 2ms     | 100ms      | **(Por defecto)** Equilibrado para la mayoría de juegos |
| **esports** | 1ms     | 50ms       | FPS competitivo, latencia ultra baja    |
| **legacy**  | 4ms     | 200ms      | CPUs antiguas, ahorro de batería            |
| **default** | 2ms     | 100ms      | Alias para gaming                      |

#### Argumentos CLI

| Argumento                  | Por Defecto  | Descripción                           |
| :------------------------ | :------- | :------------------------------------ |
| `--profile, -p <PROFILE>` | `gaming` | Seleccionar perfil preestablecido                 |
| `--quantum <µs>`          | perfil  | Tiempo de rebanada base en microsegundos       |
| `--new-flow-bonus <µs>`   | perfil  | Déficit extra para tareas recién despertadas   |
| `--starvation <µs>`       | perfil  | Tiempo máximo de ejecución antes de la interrupción forzada |
| `--verbose, -v`           | `false`  | Activar visualización de estadísticas TUI en vivo         |
| `--interval <secs>`       | `1`      | Intervalo de actualización de TUI                  |

#### Ajuste por Nivel (Perfil Gaming)

| Nivel           | Multiplicador de Quantum | Rebanada Efectiva | Límite de Privación |
| :------------- | :----------------- | :-------------- | :--------------- |
| T0 Crítico    | 0.75x              | 1.5ms           | 3ms              |
| T1 Interactivo | 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)

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

- ¿Listo para producción? <Icon name="approve-check" color="var(--sl-color-text-accent)" size="2rem" />

Planificador ligero optimizado para preservar la localidad tarea-CPU.

Cuando el sistema no está saturado, el planificador prioriza mantener las tareas en la misma CPU usando DSQs locales. Esto no solo mantiene la localidad, sino que también reduce la contención de bloqueos en comparación con los DSQs compartidos, permitiendo una buena escalabilidad en muchos CPUs.

- Casos de uso:
  - Planificador de propósito general: el planificador debería adaptarse tanto a cargas de trabajo de servidor como de escritorio.

#### Modos del Planificador

##### Auto

* **Flags de línea de comandos:** Ninguna.
* **Descripción:**

##### Gaming

* **Flags de línea de comandos:** `-s 700 -S`
* **Descripción:** Sacrifica throughput para una mejor consistencia en el rendimiento de Gaming reduciendo la contención en núcleos SMT compartidos.

##### Ahorro de Energía

* **Flags de línea de comandos:** `-m powersave`
* **Descripción:** Prioriza la eficiencia energética. Favorece núcleos menos potentes (por ejemplo, E-cores en Intel).

##### Baja Latencia

* **Flags de línea de comandos:** `-s 700 -S -m performance -w`
* **Descripción:** Diseñado para reducir la latencia a costa del throughput. Adecuado para aplicaciones de tiempo real flexible como el procesamiento de audio y multimedia. Otorga una distribución de carga más uniforme en los núcleos disponibles sacrificando eficiencia.

##### Servidor

* **Flags de línea de comandos:** `-s 20000 -c 75 -p 250`
* **Descripción:** Habilita la afinidad del espacio de direcciones para mejorar la localidad y el rendimiento en ciertas cargas de trabajo sensibles a la caché. La duración de la rebanada se establece en 20ms y el sondeo que monitorea con qué frecuencia el planificador compara la utilización de la CPU con el umbral de ocupación de la CPU para decidir cuándo el sistema está ocupado.

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

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

¿Listo para producción? <Icon name="approve-check" color="var(--sl-color-text-accent)" size="2rem" />

Un planificador que se enfoca en asegurar la equidad entre tareas y la predictibilidad del rendimiento.

Opera utilizando una política de [plazo más próximo primero (EDF)](https://www.geeksforgeeks.org/operating-systems/earliest-deadline-first-edf-cpu-scheduling-algorithm/), donde a cada tarea se le asigna un peso de "latencia". Este peso se ajusta dinámicamente según la frecuencia con la que una tarea libera la CPU antes de que se agote su porción de tiempo completa.

A las tareas que liberan la CPU antes de tiempo se les da un mayor peso de latencia, priorizándolas sobre las tareas que consumen completamente su porción de tiempo.

- Casos de uso:
  - Videojuegos
  - Cargas de trabajo sensibles a la latencia como multimedia o procesamiento de audio en tiempo real
  - Necesidad de respuesta en situaciones de sobrecarga
  - Consistencia en el rendimiento
  - Servidor

#### Modos del Planificador

##### Baja Latencia

* **Flags de línea de comandos:** `-m performance -w -C 0`
* **Descripción:** Diseñado para reducir la latencia a costa del throughput. Adecuado para aplicaciones de tiempo real flexible como el procesamiento de audio y multimedia.

##### Gaming

* **Flags de línea de comandos:** `-m all`
* **Descripción:** Optimiza para alto rendimiento en juegos.

##### Ahorro de Energía

* **Flags de línea de comandos:** `-m powersave -I 10000 -t 10000 -s 10000 -S 1000`
* **Descripción:** Prioriza la eficiencia energética. Favorece núcleos menos potentes (por ejemplo, E-cores en Intel) e introduce un ciclo de inactividad forzada cada 10ms para aumentar el ahorro de energía.

##### Servidor

* **Flags de línea de comandos:** `-m all -s 20000 -S 1000 -I -1 -D -L`
* **Descripción:** Ajustado para cargas de trabajo de servidor. Intercambia capacidad de respuesta por throughput.

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

**Desarrollado por: Galih Tama (galpt [GitHub](https://github.com/galpt))**

¿Listo para producción? <Icon name="approve-check" color="var(--sl-color-text-accent)" size="2rem" />

scx_flow es un planificador basado en presupuesto que clasifica las tareas en uno de cuatro niveles FIFO O(1) según cuánto presupuesto les queda. Sin heurísticas, sin algoritmos de puntuación, sin ajuste adaptativo — cada decisión proviene de un solo número: *presupuesto restante*.

- Casos de uso:
  - Multitarea de propósito general en escritorio y estación de trabajo
  - Videojuegos con aplicaciones de fondo abiertas
  - Trabajo de desarrollo con compilaciones, pruebas o contenedores ejecutándose
  - Cualquier escenario donde la capacidad de respuesta interactiva bajo carga mixta importe
  - Sistemas que necesitan planificación determinista y explicable (control embebido, robótica, aviónica)

#### Cómo funciona — el presupuesto

Piensa en cada tarea como si tuviera un "presupuesto de capacidad de respuesta". Mientras una tarea duerme (esperando algo que hacer), acumula presupuesto. Cuando se despierta y se ejecuta, lo gasta. Las tareas que se despiertan aún con presupuesto son señal de interactividad — se despachan inmediatamente a la CPU donde se ejecutaron por última vez, saltándose el sistema de niveles por completo. Las tareas que agotan su presupuesto se vuelven a encolar en uno de los cuatro niveles FIFO.

##### Los cuatro niveles de despacho

Cuando una tarea se vuelve a encolar (no un despertar), su presupuesto restante decide en qué nivel aterriza:

| Nivel | Umbral de presupuesto | Qué tipo de tareas terminan aquí |
|---|---|---|
| **Priority** | ≥ 1.5ms | Tareas interactivas que duermen a menudo y se ejecutan brevemente |
| **Normal** | ≥ 1ms | Tareas típicas con presupuesto decente restante |
| **Low** | ≥ 0.5ms | Tareas con poco presupuesto restante |
| **Deficit** | < 0.5ms | Workers bulk, consumidores de CPU, trabajos en segundo plano |

Cada nivel es una cola FIFO simple — O(1) encolar, O(1) desencolar. Sin recorridos de árbol, sin recálculos de prioridad.

##### Sin privación, sin inversión de prioridad

La función de despacho no solo vacía Priority primero cada vez. Rota el nivel de inicio en cada llamada — `gen & 3` decide dónde empezar. Así que el nivel Deficit nunca espera más de 3 ciclos de despacho antes de ser atendido primero. Esto significa que los workers bulk progresan incluso bajo carga interactiva pesada, y no hay inversión de prioridad porque ningún nivel único puede monopolizar la CPU.

##### Los despertares saltan la fila por completo

Cuando una tarea se despierta (estaba durmiendo y ahora tiene algo que hacer), no espera en ninguna cola de nivel. Va directamente a la CPU donde se ejecutó por última vez vía `SCX_DSQ_LOCAL_ON` — caché caliente e inmediato. Esto es lo que mantiene las tareas interactivas rápidas: una pestaña de Discord o navegador durmiendo se despierta con presupuesto y se despacha en microsegundos, no milisegundos.

##### Las tareas fijas siempre van primero

Las tareas que no pueden migrar entre CPUs (setaffinity) tienen su propia cola FIFO por CPU que tiene prioridad absoluta sobre cualquier nivel. Se despachan antes de que cualquier cosa del sistema de niveles se ejecute en esa CPU.

##### El resultado

Las tareas interactivas (entrada de teclado, actualizaciones de UI, hilos de audio, sondeo de red) casi siempre se despiertan con presupuesto y obtienen el carril rápido. El trabajo batch pesado en CPU (compilación, descargas, indexación en segundo plano) agota su presupuesto y se asienta en el nivel Deficit, donde aún progresa gracias al despacho rotativo. Sin ajuste necesario.

##### Sin perfiles, sin autotuning, sin modos

scx_flow **no** tiene modos Gaming, Power Save, o Low Latency — y a diferencia de versiones anteriores, tampoco tiene un bucle de control adaptativo. El despacho de nivel rotativo y los umbrales de presupuesto son constantes en tiempo de compilación. Lo que obtienes es lo que se ejecuta: determinista, explicable e idéntico en cada sistema. Si una tarea tiene presupuesto, obtiene prioridad. Si no, comparte el nivel Deficit de forma justa. Esa es toda la política.

#### Interfaz Web

Cuando scx_flow se inicia, sirve automáticamente un panel de métricas en vivo en **[http://localhost:50005](http://localhost:50005)**.

El panel muestra:
- Cuántos despachos han pasado por cada nivel (Priority / Normal / Low / Deficit)
- Información del sistema: tareas en ejecución, tiempo de actividad, conteo total de despachos
- Una barra de distribución de niveles para ver de un vistazo si el trabajo interactivo o bulk domina
- Cada tarjeta de métrica es clicable — abre un modal de historial con sparklines y un gráfico de barras
- Todos los valores se actualizan cada segundo vía sondeo — sin necesidad de actualizar la página

Si la página no carga, el planificador puede haber dejado de ejecutarse (el kernel vuelve al EEVDF integrado).

```sh
# Deshabilita la interfaz web si no la necesitas:
sudo scx_flow --no-webui
```

Cuando `scx_loader` se ejecuta con endurecimiento de systemd que restringe familias de sockets (`RestrictAddressFamilies`, `SocketBindDeny`), la vinculación TCP está bloqueada y scx_flow vuelve a un socket Unix en `/tmp/scx_flow.sock`. En ese caso, el navegador no puede acceder al panel directamente — ejecuta temporalmente `sudo scx_flow --no-webui` para silenciar errores si no necesitas la interfaz.

#### Argumentos CLI

| Argumento | Descripción |
|---|---|
| `--no-webui` | Deshabilitar la interfaz web integrada |
| `-d, --debug` | Activar registro de nivel de depuración |
| `-V, --version` | Imprimir versión del planificador y salir |

:::note
scx_flow **no** tiene modos de perfil de scx_loader (Gaming, Power Save, Low Latency, Server). Cada decisión de planificación se deriva directamente del presupuesto de la tarea — sin perfiles necesarios.
:::

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

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

- ¿Listo para producción? <Icon name="close" color="var(--sl-color-text-accent)" size="2rem" />

scx_forge contiene dos partes:

1. Un planificador base orientado a IA diseñado para usarse junto con la segunda parte.
2. Un agente destinado a usarse con el planificador base para proporcionar una experiencia de planificación más orientada a la IA, más optimización en el lugar por parte del agente mismo.

El agente permite configurar tu modelo de IA, la carga de trabajo que quieres optimizar y el objetivo general que quieres lograr. El agente entonces intentará optimizar el planificador para tu carga de trabajo y objetivo específicos.

¿Cómo? A través del [archivo spec.toml](https://github.com/sched-ext/scx/blob/main/tools/scx_forge_agent/spec.toml) que se usa para iniciar el bucle de optimización.

Básicamente, este planificador es perfecto para quienes quieran optimizar una carga de trabajo específica mediante un agente de IA.

Para saber más al respecto, consulta el [README de scx_forge_agent](https://github.com/sched-ext/scx/tree/main/tools/scx_forge_agent).

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

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

- ¿Listo para producción? <Icon name="approve-check" color="var(--sl-color-text-accent)" size="2rem" />

Breve introducción a LAVD de Changwoo:

*LAVD es un nuevo algoritmo de planificación que todavía está en desarrollo. Está
motivado por las cargas de trabajo de los videojuegos, que son críticas en latencia y
con mucha comunicación. Su objetivo es minimizar los picos de latencia mientras se mantiene
un buen rendimiento general y un uso justo del tiempo de CPU entre las tareas.*

- Casos de uso:
  - Videojuegos
  - Producción de audio
  - Cargas de trabajo sensibles a la latencia
  - Uso de escritorio
  - Gran interactividad bajo cargas de trabajo intensivas
  - Ahorro de energía

Una de las capacidades principales e increíbles que incluye LAVD es la **Compactación de Núcleos (Core Compaction)**, que sin entrar en detalles técnicos: cuando el uso de la CPU es < 50%, los núcleos actualmente activos funcionarán por más tiempo y a una frecuencia más alta. Mientras tanto, los núcleos inactivos permanecerán en Estado-C (Reposo) por una duración mucho más larga, logrando un menor consumo de energía general.

##### Modos del Planificador

##### Gaming y Baja Latencia

* **Flags de línea de comandos:** `--performance`
* **Descripción:** Maximiza el rendimiento utilizando todos los núcleos disponibles, priorizando los núcleos físicos.

##### Ahorro de Energía

* **Flags de línea de comandos:** `--powersave`
* **Descripción:** Minimiza el consumo de energía mientras mantiene un rendimiento razonable. Prioriza los núcleos e hilos eficientes sobre los núcleos físicos.

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

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

*Un planificador de clasificación por comportamiento con colocación consciente de la topología. Puntuación impulsada por EWMA (frecuencia de despertar, tasa de cambio de contexto, varianza de tiempo de ejecución) que clasifica tareas en tres niveles — LAT_CRITICAL, INTERACTIVE, BATCH — cada uno con su propia rebanada, reglas de interrupción y enrutamiento DSQ. La colocación está impulsada por resistencia efectiva (R_eff) en el gráfico de topología de la CPU, derivada de una pseudoinversa Laplaciana; los DSQs por CPU son robados por trabajo en orden R_eff para mantener el trabajo caliente en caché caliente. Cada constante de tiempo — rescate de estancia, objetivo CoDel, techo vtime, umbral longrun — se deriva de un único valor tau (el recíproco del autovalor de Fiedler), por lo que el planificador se autocalibra desde laptops 2C hasta servidores 32C+ sin ajuste. Un oscilador armónico amortiguado adapta el objetivo de detención CoDel desde la presión de rescate cada tick. Un bucle de control adaptativo Rust de 1Hz (actualización de pesos multiplicativos sobre seis perfiles expertos) ajusta los parámetros de planificación desde telemetría de histograma BPF, sincronizado con el estado del oscilador BPF para evitar doble corrección. Una base de datos persistente de procesos aprende clasificaciones de tareas entre reinicios. Consciente de NUMA, correcto en hotplug.*

- Casos de uso:
  - Videojuegos
  - Uso de escritorio
  - Producción multimedia/audio
    - Compilación de código fuente
    - Cargas de trabajo intensivas en ZFS / almacenamiento
    - Cargas de trabajo mixtas
    - Interactividad bajo saturación sostenida de CPU

##### Modos del Planificador
Default (Adaptativo)
- **Flags de línea de comandos:** (ninguna — se ejecuta en modo adaptativo por defecto)
- **Descripción:** Modo adaptativo completo. El bucle de control Rust detecta el régimen de carga de trabajo (LIGHT / MIXED / HEAVY) y ajusta los parámetros de planificación en tiempo real. Mejor para uso general de escritorio y videojuegos.

###### Solo BPF
- **Flags de línea de comandos:** `--no-adaptive`
- **Descripción:** Deshabilita el bucle de control adaptativo Rust. El planificador BPF se ejecuta con parámetros de ajuste estáticos. Menor sobrecarga, útil para benchmarks o si la capa adaptativa está sobre-corrigiendo en tu carga de trabajo.

###### Verbose / Debug
- **Flags de línea de comandos:** `-v` o `--verbose`
- **Descripción:** Habilita salida de telemetría detallada incluyendo conteos de despacho por nivel, tiempos de estancia y estadísticas de clasificación por comportamiento. Útil para diagnosticar el comportamiento de planificación.


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

- ¿Listo para producción? <Icon name="information" color="var(--sl-color-text-accent)" size="2rem" />
  - Sí. Si se ajusta correctamente para tu carga de trabajo y hardware específicos.

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

Un planificador de propósito general que se centra en el balanceo de carga "pick two" (elegir dos) entre
LLCs. Mantiene una alta localidad de caché y conservación del trabajo mientras proporciona
una latencia razonable.

- Casos de uso:
  - Servidor
  - Entornos de escritorio
  - Videojuegos (con algo de ajuste manual)

#### Modos del Planificador

##### Gaming

* **Flags de línea de comandos:** `--task-slice true -f --sched-mode performance`
* **Descripción:** Mejora la consistencia en el rendimiento de los videojuegos y aumenta la preferencia por planificar en núcleos de mayor rendimiento.

##### Baja Latencia

* **Flags de línea de comandos:** `-y -f --task-slice true`
* **Descripción:** Reduce la latencia haciendo que las tareas interactivas se adhieran más a la CPU a la que fueron asignadas y aumentando la estabilidad en la rebanada de tiempo.

##### Ahorro de Energía

* **Flags de línea de comandos:** `--sched-mode efficiency`
* **Descripción:** Mejora la eficiencia energética al priorizar los núcleos de bajo consumo.

##### Servidor

* **Flags de línea de comandos:** `--keep-running`
* **Descripción:** Mejora las cargas de trabajo del servidor al permitir que las tareas se ejecuten más allá de su rebanada de tiempo si la CPU está inactiva.

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

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

- ¿Listo para producción? <Icon name="close" color="var(--sl-color-text-accent)" size="2rem" />
  - Este planificador todavía es experimental y no se recomienda para uso en producción.

:::note
Para deshabilitar eficazmente los "ticks" en las CPUs "sin ticks", el kernel debe arrancarse con `nohz_full`. Ten en cuenta que `nohz_full` introduce una sobrecarga en las llamadas al sistema (syscall), por lo que esto puede afectar negativamente a las cargas de trabajo sensibles a la latencia.
:::

scx_tickless es un planificador orientado a servidores, diseñado para computación en la nube, virtualización y cargas de trabajo de computación de alto rendimiento.

El planificador funciona enrutando todos los eventos de planificación a través de un grupo de CPUs primarias asignadas para manejar estos eventos. Esto permite deshabilitar el "tick" del planificador en otras CPUs, reduciendo el ruido del sistema operativo.

- Casos de uso:
  - Computación en la nube
  - Virtualización
  - Cargas de trabajo de computación de alto rendimiento
  - Servidor

#### Modos del Planificador

##### Gaming

* **Flags de línea de comandos:** `-f 5000 -s 5000`
* **Descripción:** Aumenta el rendimiento en videojuegos al incrementar la frecuencia con la que el planificador detecta la contención de la CPU y activa cambios de contexto con una rebanada de tiempo más corta.

##### Ahorro de Energía

* **Flags de línea de comandos:** `-f 50`
* **Descripción:** Mejora la eficiencia energética al reducir las comprobaciones de contención.

##### Baja Latencia
* **Flags de línea de comandos:** `-f 5000 -s 1000`
* **Descripción:** Similar al perfil de videojuegos pero con una rebanada aún más reducida.

##### Servidor

* **Flags de línea de comandos:** `-f 100`
* **Descripción:** Reduce la frecuencia con la que el planificador comprueba la contención de la CPU para mejorar el throughput a costa de la capacidad de respuesta.

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

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

¿Listo para producción? <Icon name="information" color="var(--sl-color-text-accent)" size="2rem" />

Para escenarios de producción críticos en cuanto a rendimiento, es probable que otros planificadores muestren un mejor desempeño, ya que delegar todas las decisiones de planificación al espacio de usuario tiene un cierto costo (incluso si es mínimo).

Sin embargo, un planificador implementado completamente en el espacio de usuario tiene el potencial de integrarse sin problemas con bibliotecas sofisticadas, herramientas de trazado, servicios externos (por ejemplo, IA), etc.

Por lo tanto, podría haber situaciones en las que los beneficios superen la sobrecarga, justificando el uso de este planificador en un entorno de producción.

Comparte similitudes con bpfland, hecho con la intención de ser fácil de leer y entender cómo funciona debido a su implementación en el espacio de usuario.

Ten en cuenta que hay una ligera desventaja en el throughput al usar un planificador en el espacio de usuario.

- Casos de uso:
  - Cargas de trabajo de baja latencia (Videojuegos, videoconferencias y transmisiones en vivo)
  - Uso de escritorio

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

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

- ¿Listo para producción? <Icon name="information" color="var(--sl-color-text-accent)" size="2rem" />
  - Sí. Si se ajusta correctamente.

Rusty ofrece una amplia gama de características que mejoran sus capacidades, proporcionando una mayor flexibilidad para diversos casos de uso.
Una de estas características es la capacidad de ajuste, que te permite personalizar Rusty para que se adapte a tus preferencias y requisitos específicos.

- Casos de uso:
  - Videojuegos
  - Cargas de trabajo sensibles a la latencia
  - Uso de escritorio
  - Producción multimedia/audio
  - Gran interactividad bajo cargas de trabajo intensivas
  - Ahorro de energía

## Configuración y pruebas de rendimiento

### LAVD Autopilot y Autopower

*Citas de Changwoo Min:*
- En modo autopilot, el planificador ajusta su modo de energía `Powersave, Balanced, o Performance` según la carga del sistema, específicamente la utilización de la CPU.

- Autopower: Decide automáticamente el modo de energía del planificador basándose en el perfil de energía del sistema, también conocido como EPP (Energy Performance Preference).

```sh
# Autopower se puede activar con la siguiente flag:
--autopower
# ej:
scx_lavd --autopower
```

### ananicy-cpp y sched-ext

:::note[Actualización sobre ananicy-cpp y sched-ext]
Tras un mayor desarrollo de los planificadores, ananicy-cpp suele ser compatible para su uso junto a ellos. Sin embargo, si experimentas bloqueos o inestabilidad, considera desactivarlo como paso para solucionar problemas.
:::

Para desactivar/detener ananicy-cpp, ejecuta el siguiente comando:

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

### Cambio de perfiles de energía de scx_loader

Implementado en el paquete `power-profiles-daemon` proporcionado por CachyOS, que incluye un [parche personalizado](https://github.com/CachyOS/CachyOS-PKGBUILDS/blob/master/power-profiles-daemon/0001-Add-support-for-scx_loader-modes-switching.patch) para admitir el cambio de perfiles de energía de `scx_loader`.

- Si `scx_loader` se está ejecutando, al usar [game-performance](/es/configuration/gaming#cambio-de-perfil-de-energia-bajo-demanda), cambiará automáticamente el planificador activo al perfil `Gaming` cuando se inicie un juego y volverá al perfil predeterminado cuando el juego se cierre.
- Al cambiar entre perfiles de energía, por ejemplo, en KDE Plasma o GNOME usando el selector de perfiles de energía, `scx_loader` cambiará automáticamente al perfil de planificador correspondiente:

| Perfil de Energía       | Perfil del Planificador  |
| ------------------- | ------------------ |
| Power Saver         | Power Save         |
| Balanced            | Auto               |
| Performance         | Gaming             |

### Realizar benchmarks y comparar planificadores con cachyos-benchmarker

La herramienta [cachyos-benchmarker](https://github.com/CachyOS/cachyos-benchmarker) proporciona una manera fácil de evaluar y comparar el rendimiento de diferentes planificadores de CPU.

Ejecuta un conjunto completo de benchmarks para medir el rendimiento de la CPU, la memoria y el sistema en general bajo diversas cargas de trabajo.

Se incluyen los siguientes benchmarks:

| Prueba                      | Mide                                         | Herramienta  |
| --------------------------- | -------------------------------------------- | ------------ |
| **stress-ng cpu-cache-mem** | Rendimiento de CPU, caché y memoria        | `stress-ng`  |
| **Compilación de FFmpeg**   | Rendimiento de compilación en paralelo       | `make`       |
| **Codificación x265**       | Rendimiento de codificación de video         | `x265`       |
| **Hashing argon2**          | Hashing de contraseñas multihilo             | `argon2`     |
| **perf sched msg**          | Cambio de contexto y rendimiento de IPC      | `perf`       |
| **perf memcpy**             | Rendimiento de memoria `memcpy()`            | `perf`       |
| **Cálculo de primos**       | Aritmética de enteros y paralelismo        | `primesieve` |
| **NAMD**                    | Dinámica molecular (carga de trabajo científica) | `namd3`      |
| **Renderizado en Blender**  | Renderizado 3D solo con CPU                  | `blender`    |
| **Compresión xz**           | Rendimiento de compresión                    | `xz`         |
| **Compilación defconfig del kernel**  | Rendimiento de compilación del kernel        | `make`       |
| **y-cruncher**              | Precisión matemática y estrés de memoria     | `y-cruncher` |

`cachyos-benchmarker` se puede utilizar para varios propósitos, incluyendo:

- **Probar la estabilidad del planificador**
  Ejecuta el conjunto completo de benchmarks para detectar bloqueos, caídas o regresiones introducidas por cambios en el planificador.
  Si estás utilizando `scx_loader`, puedes recopilar registros en caso de un bloqueo o caída con:
  ```bash
  journalctl --unit scx_loader.service --boot 0 > crash.log
  ```
  Esto creará un archivo llamado `crash.log` en tu directorio actual.
- **Comparar el rendimiento del planificador**
  - Evaluar las diferencias de rendimiento entre planificadores. Por ejemplo, `BPFLAND vs LAVD`
- **Medir el efecto de las actualizaciones del kernel o del planificador**
  - Comparar ejecuciones antes y después de aplicar parches o cambios de versión para verificar regresiones o mejoras de rendimiento.
- **Probar ajustes de configuración**
  - Evaluar el impacto de cambios como la configuración del gobernador de la CPU, la activación/desactivación de SMT o las flags modificadas del planificador.

#### Requisitos
- 4 GB de RAM o más
- Al menos 8 GB de espacio de almacenamiento libre
- Tiempo y paciencia - **el benchmark completo puede tardar más de una hora en sistemas más lentos**

#### Instalación

Para instalar `cachyos-benchmarker`, ejecuta el siguiente comando:
```bash
sudo pacman -S cachyos-benchmarker
```

#### Ejecutando el benchmark

<Steps>
    1. Ejecuta `cachyos-benchmarker:`
        ```bash
        cachyos-benchmarker ~/cachyos-benchmarker/
        # Puedes reemplazar ~/cachyos-benchmarker/ con cualquier directorio en el que desees guardar los registros.
        ```
    2. Espera a que finalicen los pasos de preparación.
    3. Sigue las indicaciones:
        - `Do you want to drop page cache now? Root privileges needed! (y/N) y` (¿Deseas limpiar la caché de página ahora? ¡Se necesitan privilegios de superusuario! (s/N) s)
        - `Please enter a name for this run, or leave empty for default:` (Por favor, introduce un nombre para esta ejecución, o déjalo en blanco para el valor por defecto:)
    4. Espera a que terminen las pruebas.
    5. Una vez finalizado, sucederá lo siguiente:
        - Creación de un archivo de registro con un nombre como `benchie_<nombre>_<FECHA>.log` que contiene información detallada sobre la ejecución del benchmark.
          - Ejemplo: `benchie_p2dq_2025-09-29-2115.log`
          - El script `benchmark_scraper.py` se ejecutará automáticamente para generar un informe de resumen en formato HTML.
          - ¿Qué hace el script?:
            - Lee todos los archivos `benchie_*.log` en el directorio especificado.
            - Extrae los nombres, tiempos y puntuaciones de los benchmarks.
            - Los ordena o agrega.
            - Imprime un resumen limpio de los resultados en tu terminal y crea un archivo HTML que se puede abrir en un navegador.
                <details>
                <summary>Ejemplo de salida en la terminal:</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>Ejemplo en HTML del resultado de una prueba comparando dos ramas diferentes del mismo planificador:</summary>
                <ImageComponent imgsrc={import('~/assets/images/cachyos-benchmarker-example.png')} />
                </details>
    6. Para comparar dos o más ejecuciones, coloca los archivos `.log` en el mismo directorio antes de ejecutar `benchmark_scraper.py`. La herramienta los detectará y comparará automáticamente en el informe HTML.
</Steps>

### Pruebas de latencia del planificador con schbench

schbench es un benchmark de planificadores diseñado para medir la latencia del planificador bajo una carga de trabajo simulada de tipo servidor. Genera un número configurable de hilos "trabajadores" y "mensajeros", donde los mensajeros despiertan repetidamente a los trabajadores. Al medir la distribución de la latencia desde el despertar hasta la ejecución de estos hilos trabajadores, proporciona información crucial sobre la capacidad de un kernel para manejar despertares de hilos, equilibrio y contención de CPU, especialmente bajo carga.

#### Casos de uso

Puedes usar `schbench` para:

- **Evaluar la latencia del planificador:** Identificar cuán rápido se planifican los hilos después de ser despertados.
- **Comparar el rendimiento de despertar entre planificadores:** Detectar mejoras o regresiones en el cambio de contexto y la latencia de despertar.
- **Probar el efecto de parches en el kernel o el planificador:** Evaluar si los ajustes o actualizaciones afectan la equidad y la capacidad de respuesta de la planificación.

#### Instalación

`schbench` está disponible en los repositorios de CachyOS:
```bash
sudo pacman -S schbench
```

#### Ejecutando el benchmark

Una forma sencilla de ejecutar `schbench` para una prueba de latencia general es:
```bash
schbench -m 2 -t 8 -r 60
```

Este ejemplo ejecuta:
- 2 hilos mensajeros (`-m 2`)
- 8 hilos trabajadores por cada hilo mensajero (`-t 8`)
- durante 60 segundos de tiempo de ejecución total (`-r 60`)

Puedes ajustar estos valores dependiendo de la cantidad de núcleos de tu CPU y el nivel de carga deseado.

Aquí tienes una tabla que explica algunas de las opciones clave:

| Opción                       | Descripción                                                     |
| ---------------------------- | --------------------------------------------------------------- |
| `-C, --calibrate`            | Ejecuta la calibración e informa el tiempo (sin benchmark).     |
| `-L, --no-locking`           | Desactiva los spinlocks durante el trabajo de la CPU (por defecto: bloqueo activado). |
| `-m, --message-threads <n>`  | Número de hilos mensajeros (por defecto: 1).                    |
| `-t, --threads <n>`          | Hilos trabajadores por hilo mensajero (por defecto: número de CPUs). |
| `-r, --runtime <sec>`        | Duración del benchmark (por defecto: 30).                       |
| `-F, --cache_footprint <KB>` | Tamaño de la huella de caché (por defecto: 256).                |
| `-n, --operations <count>`   | Número de operaciones de "tiempo de reflexión" a realizar (por defecto: 5). |
| `-A, --auto-rps`             | Aumenta automáticamente el RPS hasta alcanzar el objetivo de utilización de la CPU. |
| `-R, --rps <count>`          | Modo de solicitudes por segundo.                                |
| `-p, --pipe <bytes>`         | Simula una prueba de transferencia por tubería.                 |
| `-w, --warmuptime <sec>`     | Duración del calentamiento antes de recopilar estadísticas (por defecto: 0). |
| `-i, --intervaltime <sec>`   | Intervalo para imprimir latencias (por defecto: 10).            |
| `-z, --zerotime <sec>`       | Intervalo para poner a cero las estadísticas de latencia (por defecto: nunca). |

#### Entendiendo la salida

Después de cada ejecución, `schbench` imprime los percentiles de latencia de esta forma:

<details>
    <summary>Ejemplo de salida</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>

##### Cómo interpretar los resultados

- **Latencias de despertar (Wakeup Latencies):**
  - Mide cuán rápido se despiertan los hilos después de ser señalados.
    - Valores más bajos aquí (especialmente el **percentil 99**) significan que el planificador es más responsivo.
- **Latencias de solicitud (Request Latencies):**
  - Representa el tiempo que se tarda en completar solicitudes entre hilos.
    - Una latencia más baja indica una mejor comunicación entre hilos y eficiencia en la planificación.
- **RPS (Solicitudes por segundo):**
  - Muestra el throughput sostenido:
    - Un **RPS promedio** más alto indica que el planificador puede manejar más trabajo por segundo bajo la configuración dada.

En conclusión:
- Un **buen planificador** mostrará **bajas latencias de despertar y de solicitud** con un **RPS consistente**.
- Un **planificador menos eficiente** puede exhibir **picos de alta latencia** o **valores de RPS inestables** a lo largo del tiempo.

:::note
Estos resultados pueden variar según la CPU, el número de núcleos, la carga del sistema y si el planificador es capaz de manejar eficientemente la arquitectura de tu CPU.
:::

### Recomendaciones para hacer benchmarks en juegos

Si tu deseo es hacer benchmarks en juegos para comparar el rendimiento de diferentes planificadores, aquí tienes algunos consejos para obtener los resultados más precisos:

- **Usa benchmarks integrados:** Muchos juegos modernos vienen con herramientas de benchmarking integradas. Estas están diseñadas para proporcionar resultados consistentes al ejecutar la misma secuencia de eventos cada vez.
  - Echa un vistazo a este [sitio web](https://www.pcgamingwiki.com/wiki/List_of_games_with_built-in_benchmarks) para ver una lista de juegos que incluyen benchmarks integrados.
- **Configuración consistente:** Asegúrate de que la configuración del juego (resolución, calidad de gráficos, etc.) sea la misma para cada prueba.
- **Cierra aplicaciones en segundo plano:** Otras aplicaciones que se ejecutan en segundo plano pueden afectar el rendimiento. Cierra los programas innecesarios para minimizar su impacto.
- Si no estás utilizando un benchmark integrado, intenta realizar las mismas acciones en el juego en cada prueba. Esto podría incluir seguir el mismo camino, participar en escenarios de combate similares o realizar las mismas tareas.
  - Incluso no apuntar al mismo lugar puede llevar a resultados de rendimiento diferentes.
- **Múltiples ejecuciones:** Realiza varias ejecuciones del benchmark y saca el promedio para tener en cuenta la variabilidad.
- **Usa herramientas de monitoreo de rendimiento:** Herramientas como MangoHud o GOverlay pueden proporcionar métricas de rendimiento en tiempo real como FPS, tiempos de fotograma y uso de CPU/GPU.
- **Aprovecha los atajos de teclado o macros:**
  - Un ejemplo es crear una combinación de teclas con la que puedas cambiar entre diferentes planificadores o cambiar sus modos sobre la marcha mientras estás en el juego.
    - Esto se puede hacer usando una herramienta como [scxctl](/es/configuration/sched-ext#como-lanzar-y-gestionar-el-planificador) o creando scripts personalizados que cambien el planificador activo y su modo.

#### Subir y compartir tus benchmarks

Este [sitio web](https://flightlesssomething.ambrosia.one/benchmarks) contiene una lista de benchmarks realizados por la comunidad utilizando diferentes planificadores o probando diversas configuraciones.

Para subir tus propios benchmarks, tendrás que vincular tu cuenta de Discord al sitio web y luego podrás enviar tus propios benchmarks.

Luego haz clic en el botón `New benchmark` y completa la información requerida.

- Puedes subir múltiples resultados para el mismo juego usando diferentes planificadores o configuraciones.
- Acepta registros tanto de MangoHud como de Afterburner.
- Permite buscar por título o descripción.

## Configuración de scx_loader

### Establecer un planificador como predeterminado (en el arranque)

Para establecer un planificador que se inicie automáticamente cuando `scx_loader` se inicie (por ejemplo, en el arranque), sigue estos pasos:

<Steps>
1. **Copia el archivo de configuración de ejemplo** al directorio de configuración:
   ```sh
   sudo mkdir -p /etc/scx_loader
   sudo cp /usr/share/scx_loader/config.toml /etc/scx_loader/config.toml
   ```

2. **Edita el archivo de configuración** con tu editor preferido:
   ```sh
   sudo nano /etc/scx_loader/config.toml
   ```

3. **Establece el planificador y modo predeterminados**. Por ejemplo, para establecer `scx_pandemonium` en modo `Auto`:
   ```toml
   # Este campo especifica el planificador que se iniciará automáticamente cuando scx_loader se inicie (por ejemplo, en el arranque).
   default_sched = "scx_pandemonium"

   # Este campo especifica el modo que se usará cuando scx_loader se inicie (por ejemplo, en el arranque).
   default_mode = "Auto"
   ```

4. **Habilita e inicia el servicio**:
   ```sh
   sudo systemctl enable --now scx_loader.service
   ```
</Steps>

#### Orden de Búsqueda de Configuración

`scx_loader` busca el archivo de configuración en el siguiente orden:

1. `/etc/scx_loader/config.toml` (Preferido)
2. `/etc/scx_loader.toml`
3. `/usr/share/scx_loader/config.toml` (Plantilla predeterminada)
4. `/usr/share/scx_loader.toml`

### Personalizar Argumentos del Planificador

Puedes personalizar los argumentos pasados a cada planificador para diferentes modos añadiendo una sección `[scheds.scx_nombre]` a tu archivo de configuración.

Para información detallada y ejemplos sobre cómo configurar argumentos por planificador, consulta la [documentación de configuración de scx_loader](https://github.com/sched-ext/scx-loader/blob/main/crates/scx_loader/configuration.md).

## Transición de scx.service a scx_loader: Una Guía Completa

:::caution
No intentes ejecutar scx_loader.service junto con scx.service, de lo contrario, el servicio del cargador se iniciará pero no hará nada.

Este conflicto surge porque ambos servicios no son conscientes el uno del otro, especialmente en lo que respecta a cuál de ellos gestiona los planificadores.
:::

:::tip
El Gestor de Kernel de CachyOS ya incluye una [GUI para gestionar el scx_loader.](/es/features/kernel_manager#gestion-del-framework-sched-ext)
:::

Primero, comencemos con una comparación detallada entre la estructura de archivos de scx.service y la estructura del archivo de configuración de scx_loader.

*Si anteriormente tenías LAVD funcionando con el antiguo scx.service como en este ejemplo a continuación:*

```sh title='Estructura del archivo scx.service'
# Lista de scx_schedulers: 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

# Establecer flags personalizadas para el planificador
SCX_FLAGS='--performance'
```

Entonces el equivalente en el archivo de configuración de scx_loader se verá así:

```sh title='Estructura del archivo scx_loader'
default_sched = "scx_lavd"
default_mode = "Auto"

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

[Para más información sobre cómo configurar el archivo scx_loader](https://github.com/sched-ext/scx-loader/blob/main/crates/scx_loader/configuration.md#scx_loader-configuration-file)

  Sigue la guía a continuación para una transición sencilla del `servicio systemd scx` a la nueva utilidad `scx_loader`.
  <Steps>
  1. ```sh title='Deshabilitando scx.service en favor de scx_loader.service'
      systemctl disable --now scx.service && systemctl enable --now scx_loader.service
      ```
  2. ```sh title='Creando el archivo de configuración para scx_loader y añadiendo la estructura por defecto'
     # El editor Micro va a crear un nuevo archivo.
     sudo micro /etc/scx_loader.toml
     # Añade las siguientes líneas:

     default_sched = "scx_bpfland" # Edita esta línea con el planificador que quieres que scx_loader inicie en el arranque
     default_mode = "Auto" # Valores posibles: "Auto", "Gaming", "LowLatency", "PowerSave".

     # Pulsa CTRL + S para guardar los cambios y CTRL + Q para salir de Micro.
     ```
  3. ```sh title='Reiniciando el scx_loader'
     systemctl restart scx_loader.service
     ```
     - Has terminado, el scx_loader ahora cargará e iniciará el planificador deseado.

  </Steps>

### Depuración en el scx_loader

<Tabs>
<TabItem label='Registro simple'>

  - ```sh title='Comprobando el estado del servicio'
    systemctl status scx_loader.service
    ```
  - ```sh title='Viendo todas las entradas de registro del servicio'
    journalctl -u scx_loader.service
    ```
  - ```sh title='Viendo solo los registros de la sesión actual.'
    journalctl -u scx_loader.service -b 0
    ```
</TabItem>
<TabItem label='Registro extendido'>

*Para obtener un registro más detallado, sigue estos pasos.*
  - ```sh title='Editar el archivo del servicio'
     sudo systemctl edit scx_loader.service
     ```
  - ```sh title='Añade la siguiente línea bajo la sección [Service]'
     Environment=RUST_LOG=trace
     ```
  - ```sh title='Reinicia el servicio'
     sudo systemctl restart scx_loader.service
     ```
  - Revisa los registros de nuevo para obtener información de depuración más detallada.
</TabItem>

</Tabs>

## Preguntas Frecuentes

### Hay tantas opciones... ¿por qué no hacer un solo planificador que sea bueno en todo?

La razón principal es que no existe una solución única para todo cuando se trata de planificación de CPU. Diferentes cargas de trabajo tienen diferentes requisitos y prioridades, y un planificador optimizado para un tipo de carga de trabajo puede no funcionar bien para otro.

Podrías ver los planificadores de CPU como diferentes pares de zapatos, cada uno diseñado para una actividad específica. Por ejemplo, ejecutar un juego en un planificador optimizado para cargas de trabajo de servidor puede llevar a un rendimiento subóptimo y mayor latencia, mientras que usar un planificador diseñado para juegos en un servidor puede resultar en una utilización ineficiente de recursos y menor throughput.

Esa es la magia de sched-ext. Las limitaciones ya no son un problema.

### ¿Por qué el planificador X rinde peor que el otro?

- Hay muchas variables a considerar al compararlos. Por ejemplo, ¿cómo miden el peso de una tarea? ¿Priorizan las tareas interactivas sobre las no interactivas?
  En última instancia, depende de sus decisiones de diseño.

### ¿Por qué todo el mundo sigue diciendo que este planificador X es el mejor para el caso X pero no me rinde tan bien?

- Al igual que en la respuesta anterior, la elección de la CPU y su diseño, como la disposición de los núcleos, cómo comparten la caché entre los núcleos y otros factores relacionados, pueden hacer que el planificador funcione de manera menos eficiente.
- Por eso tener opciones es uno de los puntos fuertes del framework sched-ext, así que no tengas miedo de probar uno y ver cuál funciona mejor para tu caso de uso. `Ejemplos: estabilidad de fps, rendimiento máximo, capacidad de respuesta bajo cargas de trabajo intensivas, etc.`

### Los casos de uso de estos planificadores son bastante similares... ¿por qué es eso?

Principalmente porque son planificadores multipropósito, lo que significa que pueden adaptarse a una variedad de cargas de trabajo, aunque puede que no destaquen en todas las áreas.

- Para determinar qué planificador se adapta mejor a ti, no hay mejor consejo que probarlo por sí mismo.

### ¿Por qué me falta un planificador que algunos usuarios mencionan o prueban en el servidor de Discord de CachyOS?
Asegúrate de que estás utilizando la versión de vanguardia del paquete scx-scheds, llamada `scx-scheds-git`

- Una de las razones será que este planificador es muy nuevo y actualmente está siendo probado por los usuarios, por lo tanto, aún no se ha añadido al paquete `scx-scheds-git`.

### ¿Por qué el planificador se ha colgado de repente? ¿Es inestable?

- *Podría haber algunas razones por las que esto ocurrió:*
  - Una de las razones más comunes es que estabas usando ananicy-cpp junto con el planificador. Por eso añadimos esta [advertencia](/es/configuration/sched-ext#ananicy-cpp-y-sched-ext)
  - Otra razón podría ser que la carga de trabajo que estabas ejecutando excedió los límites y la capacidad del planificador, provocando que se detuviera.
    - Ejemplo de una carga de trabajo irrazonable: `hackbench`
  - O la razón más obvia, has encontrado un error en el planificador. Si es así, por favor repórtalo como un "issue" en su [GitHub](https://github.com/sched-ext/scx/issues) o hágaselo saber
    en el canal de Discord de CachyOS `sched-ext`

### He utilizado previamente el scx_loader en la GUI del Gestor de Kernel. ¿Aún así necesito seguir los pasos de transición?

- En este caso particular, no, no es necesario porque el Gestor de Kernel ya se encarga del proceso de transición.
  - *A menos que hayas añadido previamente flags personalizadas en `/etc/default/scx` y todavía quieras usarlas.*

## Aprende Más

:::note[Créditos]
Algunos de los enlaces a continuación fueron referenciados originalmente del [repositorio de GitHub de sched-ext](https://github.com/sched-ext/scx?tab=readme-ov-file#sched_ext-schedulers-and-tools).
Todo el crédito va para los mantenedores y contribuidores de sched-ext por recopilar y compartir estos excelentes recursos.
:::

- [Lista de reproducción de YT de Sched_ext](https://youtube.com/playlist?list=PLLLT4NxU7U1TnhgFH6k57iKjRu6CXJ3yB&si=DETiqpfwMoj8Anvl)
- [LWN: The extensible scheduler class (Febrero, 2023)](https://lwn.net/Articles/922405/)
- [Blog de arighi: Implement your own kernel CPU scheduler in Ubuntu with sched_ext (Julio, 2023)](https://arighi.blogspot.com/2023/07/implement-your-own-cpu-scheduler-in.html)
- [Charla de David Vernet: Kernel Recipes 2023 - sched_ext: pluggable scheduling in the Linux kernel (Septiembre, 2023)](https://youtu.be/8kAcnNVSAdI?si=F5Q-dkSS_sG9BTXA)
- [Blog de Changwoo: sched_ext: a BPF-extensible scheduler class (Part 1) (Diciembre, 2023)](https://blogs.igalia.com/changwoo/sched-ext-a-bpf-extensible-scheduler-class-part-1/)
- [Blog de arighi: Getting started with sched_ext development (Abril, 2024)](https://arighi.blogspot.com/2024/04/getting-started-with-sched-ext.html)
- [Blog de Changwoo: sched_ext: scheduler architecture and interfaces (Part 2) (Junio, 2024)](https://blogs.igalia.com/changwoo/sched-ext-scheduler-architecture-and-interfaces-part-2/)
- [Canal de YT de arighi: scx_bpfland Linux scheduler demo: topology awareness (Agosto, 2024)](https://youtu.be/R-FEZOveG-I)
- [Charla de David Vernet: Kernel Recipes 2024 - Scheduling with superpowers: Using sched_ext to get big perf gains (Septiembre, 2024)](https://youtu.be/Cy7-oqdcUCs?si=bjKu3uidOdIzzAWv)
