Linux 7.3 y sched_ext: schedulers BPF por cgroup

Si en un mismo servidor corrés una base de datos, workers de batch y servicios sensibles a la latencia, sabés que el scheduler de CPU del kernel es una sola política para todos. Linux 7.3, que según Phoronix debería salir alrededor del 18 de octubre de 2026, cierra una pieza larga de sched_ext: los sub-schedulers por cgroup. Todavía no es algo para producción mañana, pero sí para empezar a evaluar.

sched_ext es la clase de scheduler extensible de Linux: permite escribir políticas de planificación de CPU como programas BPF y cargarlas en runtime, sin recompilar el kernel. Está en mainline desde la serie 6.12. Los sub-schedulers por cgroup permiten que un scheduler BPF raíz entregue un subárbol de cgroups v2 a otro scheduler BPF anidado, que decide solo sobre esas tareas.

¿Qué se completó exactamente en Linux 7.3?

Linux 7.3 y sched_ext: un scheduler BPF por cgroup en tu servidor

Se completó la ruta de enqueue de la planificación jerárquica, y con eso el soporte de sub-schedulers quedó declarado "feature complete". Según el mensaje del merge citado por LWN en su nota sobre la ventana de merge de 7.3, "a root BPF scheduler can now hand a cgroup subtree over to a nested sub-scheduler together with revocable CPU grants" (un scheduler BPF raíz puede entregar un subárbol de cgroups a un sub-scheduler anidado junto con permisos de CPU revocables).

En la práctica, el cambio tiene estas piezas:

Delegación por subárbol: los sub-schedulers toman el control de su subárbol de cgroups y reciben los callbacks de cgroup de ese subárbol, según Phoronix.
CPUs prestadas y revocables: el scheduler padre concede y retira capacidades por CPU a sus hijos. Phoronix menciona encolar, desalojar (preemption) y control de frecuencia.
Dueño único de las decisiones: el sub-scheduler decide todo sobre sus tareas en esas CPUs, según el mensaje del merge.
Migración entre cgroups: si movés una tarea a un cgroup gobernado por otro sub-scheduler, el kernel la re-asigna al nuevo dueño. Según Phoronix, antes eso no ocurría y provocaba planificación con el scheduler equivocado y un use-after-free; el problema quedó corregido.

¿De dónde viene esto? La línea de tiempo de los sub-schedulers

El soporte llegó en etapas durante varios ciclos del kernel, con el cierre en 7.3. El primer RFC público apareció en septiembre de 2025, según LWN. Ya definía que los schedulers pueden engancharse "en cualquier parte de la jerarquía de cgroups", con un tope de SCX_SUB_MAX_DEPTH niveles, hoy fijado en 4.

Antes de 7.3: según Phoronix, solo se podía delegar el dispatching, sin la ruta de enqueue.
Linux 7.2: continuó el trabajo hacia el soporte completo.
Linux 7.3: se completa el enqueue y el soporte se declara completo. El 7.3-rc1 cerró la ventana de merge (LWN lo reseñó el 31 de agosto de 2026) y el rc7 salió el 12 de octubre.

¿Qué problema resuelve en servidores multi-carga?

Resuelve el conflicto entre cargas con necesidades opuestas en la misma máquina. Un servicio de latencia baja y un job de throughput quieren políticas distintas, y con un único scheduler global la salida suele ser un compromiso o una partición rígida de CPUs. Los sub-schedulers apuntan a una tercera opción: políticas distintas por subárbol, con reparto dinámico de CPU desde el padre.

Esto es lo que ya podías hacer y lo que cambia:

Antes con cgroups v2: cpu.weight, cpu.max y cpuset ajustan cuánta CPU recibe un grupo, pero la política interna sigue siendo la del scheduler del kernel (EEVDF en los kernels recientes).
Antes con sched_ext global: un scheduler como scx_layered permite políticas declarativas por cgroup en TOML, pero sigue siendo un único scheduler decidiendo para todo el sistema.
Ahora: cada dominio puede tener su propio programa BPF con su propia lógica, y el padre conserva el control del presupuesto de CPU.

Mi lectura: el caso de uso más claro no es el servidor web típico, sino el host con cargas muy heterogéneas: nodos de Kubernetes con pods de latencia y de batch mezclados, o hosts con VMs y contenedores. Si tu carga es homogénea, el beneficio probablemente no justifica la complejidad.

¿Se puede usar en producción hoy?

Todavía no conviene en producción. A la fecha de esta nota (14 de octubre de 2026), Linux 7.3 es un release candidate, y no es de esperar que los kernels de las distros estables lo traigan en el corto plazo. Además, hay puntos abiertos que verificar antes de apostar por esto:

Aislamiento de fallas parcial: según el RFC original citado por LWN, habilitar o deshabilitar un sub-scheduler solo hace bypass de las tareas del subárbol afectado. Eso da "aislamiento razonable" ante fallas de un scheduler hijo, no aislamiento total.
Problemas conocidos: no verifiqué si quedan puntos abiertos en 7.3, así que revisá las notas de release.
Herramientas en userspace: no encontré confirmación de que los schedulers del repositorio sched-ext/scx ya aprovechen la API de sub-schedulers. Verificalo en el repo antes de planificar.
Madurez: es un esqueleto que recién ahora cierra el ciclo, y no existe todavía experiencia operativa acumulada con él.

Mi postura: sched_ext global ya es evaluable en staging, mientras que los sub-schedulers son para laboratorio y para seguir de cerca durante los próximos meses.

¿Qué requisitos tiene un servidor para usar sched_ext?

Necesitás un kernel con CONFIG_SCHED_CLASS_EXT, soporte BPF con JIT y BTF, y cgroups v2. Según una guía de terceros de Botmonster, la base es:

CONFIG_SCHED_CLASS_EXT=y
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_JIT=y
CONFIG_DEBUG_INFO_BTF=y

Los sub-schedulers se atan a cgroup v2, así que tu host tiene que estar en v2. Si todavía no migraste, mirá nuestra nota sobre failCgroupV1: false en Kubernetes, que explica por qué cgroup v1 tiene los días contados.

¿Cómo probar sched_ext hoy en un servidor de pruebas?

Probalo en una VM o servidor descartable, nunca en el de producción. Estos pasos usan solo comandos de lectura o los que describe la guía citada, y no tocan el scheduler de ningún host que importe:

Verificá la config del kernel: grep CONFIG_SCHED_CLASS_EXT /boot/config-$(uname -r) (o zgrep ... /proc/config.gz según la distro).
Confirmá cgroup v2: stat -fc %T /sys/fs/cgroup debería devolver cgroup2fs.
Instalá los schedulers del proyecto: compilá sched-ext/scx o usá el paquete de tu distro, y revisá su documentación para la versión actual.
Cargá scx_layered con una política mínima: es el más cercano al caso servidor, porque define políticas por cgroup en TOML sin escribir BPF.
Mirá el estado: cat /sys/kernel/sched_ext/root/ops muestra el scheduler activo, y dmesg | grep sched_ext muestra las razones si el kernel lo expulsa.
Medí antes y después: latencia p99 de tu servicio sensible y throughput del batch, con la misma carga, contra el baseline de EEVDF.

Un dato de seguridad operativa: sched_ext incluye un watchdog que expulsa al scheduler BPF si deja tareas sin ejecutar demasiado tiempo, y el sistema vuelve al scheduler por defecto. La guía de Botmonster indica un timeout por defecto de 30 segundos y lo expone en /sys/kernel/sched_ext/watchdog_timeout_ms. Confirmalo en la documentación de tu kernel.

¿Qué hay que vigilar de acá a los próximos meses?

El lanzamiento de 7.3: se espera alrededor del 18 de octubre, según Phoronix. Si aparece un rc8, se corre una semana.
Los kernels de tu distro: si usás una LTS, la ruta realista es un kernel HWE o uno propio. Nuestra nota sobre Ubuntu 26.04.1 LTS es una buena lectura complementaria para decidir cuándo saltar.
El soporte en scx: que los schedulers de userspace adopten la API es lo que lo va a volver usable sin escribir BPF a mano.

Preguntas frecuentes

¿Cuándo sale Linux 7.3?

Se espera alrededor del 18 de octubre de 2026, según Phoronix tras el rc7 del 12 de octubre. Si Linus Torvalds necesita un rc8, se corre una semana.

¿Qué es un sub-scheduler de sched_ext?

Es un scheduler BPF anidado que gobierna un subárbol de cgroups v2 por delegación de un scheduler padre. Usa solo las CPUs que el padre le concede, y el padre puede revocarlas.

¿Hay que escribir código BPF para usarlo?

No necesariamente para sched_ext en general: scx_layered permite definir políticas por cgroup en TOML. Para sub-schedulers con lógica propia, sí vas a necesitar un programa BPF, salvo que los schedulers de scx incorporen la API.

¿Qué pasa si un sub-scheduler falla?

El kernel puede hacer bypass de las tareas del subárbol afectado, según el diseño descrito en LWN, sin tirar abajo el resto del sistema. Es un aislamiento "razonable", no total, así que probá los casos de falla en staging.

¿Reemplaza a cpu.weight y cpu.max?

No, los complementa. Los controles de cgroup v2 siguen definiendo cuánta CPU recibe un grupo, y los sub-schedulers definen cómo se ordena y ejecuta el trabajo dentro de ese grupo.

¿Sirve en un VPS?

Solo si el kernel del guest es tuyo y tiene sched_ext habilitado. En virtualización con kernel compartido (contenedores) no vas a poder cambiar el scheduler del host, así que verificá con tu proveedor qué kernel corre tu máquina.

Conclusión

Linux 7.3 no cambia tu servidor el día del lanzamiento, pero cierra la pieza que faltaba para pasar de "un scheduler custom para toda la máquina" a "una política por carga con presupuesto de CPU controlado". Si administrás hosts con cargas mezcladas, vale la pena armar un laboratorio con sched_ext hoy y esperar a que 7.3 llegue a los kernels de tu distro.

Fuentes: Phoronix: sub-scheduler support feature complete en Linux 7.3, LWN: the rest of the 7.3 merge window, LWN: sched_ext, cgroup sub-scheduler support (RFC), Phoronix: Linux 7.3-rc7.