Linux kernel 7.2: novedades y efecto en un VPS

Novedades de Linux kernel 7.2

Linux kernel 7.2 se publicó el 16 August 2026. El cambio que merece atención es la planificación consciente de la caché, implementada mediante la nueva opción CONFIG_SCHED_CACHE. El planificador intenta mantener los hilos de un proceso en CPUs que comparten la misma caché de último nivel (LLC). Ningún otro cambio de esta versión modifica la forma en que la carga de trabajo se asigna a una CPU.

El resto de 7.2, en una línea: una reestructuración de la ruta de fast commit de ext4, mejoras en MGLRU (el código de recuperación de memoria least recently used multigeneracional), un nuevo destino dm-inlinecrypt de device mapper para el cifrado inline de dispositivos de bloques y la eliminación de la última llamada strncpy() del código fuente del kernel.

Un dato determina si la función principal puede hacer algo por usted, por lo que aparece primero. El equilibrado de carga consciente de la caché sólo se activa cuando un nodo NUMA (non-uniform memory access) contiene más de una LLC. Normalmente, un guest VPS no expone esa topología. Por tanto, en la mayoría de los guests el código se compila, pero nunca se activa. Puede comprobarlo con dos comandos, en «¿Un guest VPS detecta algo de esto?» más adelante.

Todas las afirmaciones técnicas de esta página proceden del registro de cambios de 7.2 y de la propia serie de parches de planificación consciente de la caché, revisados el 18 August 2026. Las fuentes aparecen cerca del final para que pueda compararlas con el comportamiento de su propio kernel.

Por qué el planificador necesitaba conocer las cachés

Un socket de servidor moderno no tiene una única caché de último nivel. Un paquete AMD EPYC está compuesto por varios complejos de núcleos, y cada complejo tiene su propia L3. Los procesadores Intel Xeon recientes también dividen un socket en más de un dominio de caché. Por tanto, un solo nodo NUMA puede contener cuatro, ocho o más LLC independientes, y dos hilos del mismo programa pueden terminar en cachés distintas.

Esa distribución tiene un coste. Cuando dos hilos comparten una página desde LLC distintas, cada caché mantiene su propia copia de la línea. Una escritura en un lado invalida la copia del otro, por lo que la siguiente lectura debe atravesar la interconexión o acceder a la memoria principal. Esto se denomina rebote de caché. Se refleja en ciclos de espera, no en tiempo de CPU inactiva, por lo que es fácil no detectarlo al observar la carga media.

Antes de 7.2, el equilibrador de carga colocaba las tareas usando la carga, la utilización y las CPU inactivas. No recibía ninguna información que indicara que «estas dos tareas leen la misma memoria». 7.2 añade esa información mediante una aproximación cuyo cálculo no tiene coste: los hilos de un proceso comparten un espacio de direcciones, por lo que se consideran propensos a compartir datos.

Cómo el kernel elige una LLC preferida

El seguimiento se asocia al proceso, en mm_struct, la estructura del kernel que representa un espacio de direcciones. El kernel toma periódicamente muestras de dónde se ejecutan los hilos de ese proceso y cuenta, por cada LLC, qué parte del proceso reside en ella. La LLC que contiene la mayor parte se convierte en la LLC preferida de todo el proceso. Las decisiones posteriores consultan ese único valor.

Después se utilizan dos rutas. Al despertar, el planificador orienta la elección de CPU hacia la LLC preferida del proceso, en lugar de elegir cualquier CPU libre del nodo. Durante el equilibrio de carga, cuando las tareas deben moverse entre grupos del planificador, da preferencia a las tareas que ya prefieren la LLC de destino y evita alejar una tarea de la LLC que prefiere.

Las protecciones son tan importantes como la función, porque concentrar todos los hilos de un proceso con mucha actividad en un solo dominio de caché puede sobrecargarlo mientras el resto del socket permanece inactivo. Los parámetros ajustables se encuentran en debugfs, el sistema de archivos de depuración del kernel, en /sys/kernel/debug/sched/:

• llc_aggr_tolerance, un valor de 0 a 100, define hasta qué punto agrega el kernel. 0 desactiva el planificador consciente de la caché durante la ejecución. 1 es el ajuste conservador: un proceso cuyo RSS (resident set size, su memoria residente) sea mayor que la LLC, o que ejecute más hilos que núcleos tenga la LLC, permanece donde está. 100 agrega sin tener en cuenta el tamaño ni el número de hilos.
• llc_overload_pct, con un valor predeterminado de 50, establece la utilización media por encima de la cual la LLC preferida se considera ocupada.
• llc_imb_pct, con un valor predeterminado de 20, limita el desequilibrio que puede crear una migración de agregación cuando la LLC preferida supera ese punto de sobrecarga.
• llc_epoch_period, con un valor predeterminado de 10 ms, define cada cuánto se recopila la ocupación.
• llc_epoch_affinity_timeout, con un valor predeterminado de 50 ms, define cuánto tiempo un proceso inactivo conserva su preferencia antes de que el kernel la elimine.

Consulte sus propios valores antes de cambiar cualquiera de ellos, porque una distribución puede proporcionar valores predeterminados diferentes: sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance.

Cargas de trabajo que plausiblemente mejoran y cuáles no

Las cifras siguientes son las publicadas con la serie de parches. Se midieron en hardware de clase servidor, y algunas con el control de tolerancia ajustado a un valor agresivo. Tómalas como el mejor caso en hardware físico, no como una promesa para tu equipo.

[
  {
    "label": "hackbench, 1 group, Xeon Sapphire Rapids",
    "gain_pct": 30.57
  },
  {
    "label": "schbench, 4 threads, p99 wakeup latency, Sapphire Rapids",
    "gain_pct": 37.78
  },
  {
    "label": "ChaCha20 throughput, AMD Genoa, aggressive tolerance",
    "gain_pct": 44
  }
]

Hackbench con un solo grupo mejoró un 30.57%, y la prueba de rendimiento de ChaCha20 en AMD Genoa mejoró un 44%. Los 3 resultados se obtuvieron en hardware de servidor con varias LLC, bajo control completo del evaluador.

Una carga de trabajo que mejora suele tener estas características:

• Más de un hilo en un solo proceso, de modo que haya algo que agrupar.
• Compartición real entre esos hilos, de modo que una línea de caché transferida suponga un coste real.
• Un conjunto de trabajo que quepa en una sola LLC, porque mover un proceso que supera el tamaño de la caché no puede darle localidad de caché.
• Capacidad libre en el equipo, para que el planificador pueda elegir dónde colocar el siguiente hilo.

Estos son los casos en los que no hay nada que ganar:

• Un equipo que ya está a plena capacidad. Todas las CPU están ocupadas, por lo que la colocación es obligatoria y las mejoras publicadas disminuyen.
• Procesos de un solo hilo y grupos de procesos independientes que no comparten datos.
• Un conjunto de trabajo mucho mayor que la LLC, que el ajuste cuidadoso de llc_aggr_tolerance omite deliberadamente.
• Un nodo que informa de una sola LLC, donde la función nunca se activa.

También existe un coste, y la serie lo reconoce claramente. Recopilar la ocupación requiere trabajo en el contexto de la tarea, y en algunas pruebas la latencia de las peticiones empeoró porque ese trabajo retrasó el retorno de la tarea al espacio de usuario. La agregación también puede aumentar la variación de la latencia aunque mejore el rendimiento medio. Si te importa la cola de latencia y no el promedio, mide tu propia cola.

¿Un VPS puede ver algo de esto?

Dos hechos determinan la respuesta.

Primero, la función depende de la topología. El equilibrio de carga consciente de la caché sólo se habilita cuando existe más de una LLC dentro de un nodo NUMA, y el kernel lo registra durante la configuración de la topología. Cuando un nodo informa de una sola LLC, la ruta consciente de la caché permanece inactiva, independientemente de cómo se configuren los parámetros ajustables.

Segundo, la topología de caché que lee el guest no es la del host. Es la que presenta el modelo de CPU del hipervisor. Normalmente, un guest KVM (kernel based virtual machine) no recibe la distribución L3 real del host, por lo que razona sobre una representación simplificada.

Compruebe qué ve su propio guest:

systemd-detect-virt
lscpu --caches
cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u

index3 es la caché L3 en la mayoría de las CPU x86. Una línea que enumera todas las vCPU indica que el guest ve una sola LLC, por lo que la función no tiene nada que organizar. No such file or directory indica que no se expuso ninguna L3 al guest. En ese caso, el guest trata un nivel de caché inferior como su último nivel, con límites inventados por el hipervisor en lugar de los límites del silicio.

También existe la planificación doble, que es la salvedad real para cualquier tenant. El kernel del guest coloca los hilos en las vCPU. El kernel del host coloca esos hilos de vCPU en núcleos físicos. Un guest que agrupa cuidadosamente cuatro hilos en las vCPU 0 a 3 está expresando una preferencia sobre cuatro hilos del host. El host puede colocarlos en distintos dominios físicos de caché y moverlos después. La decisión del guest no es incorrecta, pero no es la decisión final. Ese es el mismo límite entre capas que produce el tiempo de steal que un vecino ruidoso deja en sus vCPU.

Entonces, ¿hasta dónde llega esta función para un tenant de VPS? A dos lugares. En planes donde la topología es real y no sintética, como los que ofrecen núcleos dedicados o instancias grandes con una distribución transferida, el planificador del guest está tomando decisiones sobre hardware existente. Y en el propio kernel del host del proveedor, donde la colocación consciente de la caché para los hilos de sus vCPU es una ventaja que puede aprovechar el proveedor, no el tenant. La distribución de la caché también cambia según la arquitectura. Esta es otra variable al comparar un VPS Arm con un VPS x86.

Medir el comportamiento de la caché dentro de un guest es más difícil que hacerlo sobre hardware físico. perf stat -e cache-misses suele informar de <not supported> porque el hipervisor no expone la PMU (performance monitoring unit) a los guests. Mida en su lugar el rendimiento y la latencia de su propia aplicación, y use el parámetro de debugfs como interruptor entre las dos ejecuciones.

Compruebe si el kernel tiene CONFIG_SCHED_CACHE

uname -r
grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r) || echo 'not set in this build'
sudo ls /sys/kernel/debug/sched/ | grep -i llc

CONFIG_SCHED_CACHE=y significa que el kernel se compiló con esta opción. Una línea con # CONFIG_SCHED_CACHE is not set significa que la opción existe en esa versión, pero la distribución la desactivó. La ausencia total de salida suele indicar que el kernel es anterior a la opción. uname -r lo confirmará. Algunas imágenes cloud minimalistas no incluyen el archivo /boot/config-*. En ese caso, lea zcat /proc/config.gz. Esta opción sólo funciona si el kernel se compiló con CONFIG_IKCONFIG_PROC.

La línea ls muestra los parámetros ajustables llc_* cuando la funcionalidad está compilada en el kernel. Si no muestra nada mientras CONFIG_SCHED_CACHE=y, monte primero debugfs con sudo mount -t debugfs none /sys/kernel/debug.

Para comparar la carga de trabajo con la funcionalidad activada y desactivada, registre primero el valor actual. Después tendrá que restaurarlo:

sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance
sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'

Ejecute el benchmark, vuelva a escribir el valor registrado y ejecútelo otra vez. Los cambios realizados mediante debugfs no sobreviven a un reinicio. Esto es lo que necesita durante las pruebas.

Cuándo incluirá una distribución el kernel 7.2

Mainline no es el kernel con el que arranca su VPS. La versión de uname -r procede de su distribución, y cada distribución tiene su propio proceso para llevar una versión mainline hasta su servidor.

Fedora vuelve a basar sus versiones estables en kernels mainline nuevos durante todo su periodo de soporte. Por eso, allí sudo dnf upgrade --refresh y un reinicio completan el proceso. Normalmente, es el primer lugar donde un usuario puede probar un kernel nuevo. Ese ritmo forma parte de lo que elige al ejecutar Fedora Server en un VPS.

Ubuntu publica un kernel nuevo con cada versión semestral y después lo incorpora a la versión anterior de soporte a largo plazo (LTS) mediante la pila HWE (hardware enablement). En agosto de 2026, Ubuntu 24.04 LTS todavía instala 6.8, publicado en abril de 2024, como kernel GA, mientras que su pila HWE pasó a 6.14 en agosto de 2025 y a 6.17 en febrero de 2026. Ese es el plazo realista: una versión mainline publicada en agosto de 2026 llega a una pila HWE de LTS aproximadamente un año después.

apt-cache policy linux-generic-hwe-24.04
sudo apt install --install-recommends linux-generic-hwe-24.04

Debian stable mantiene un kernel durante toda la vida de la versión y ofrece kernels más nuevos mediante backports, que se activan por paquete:

echo 'deb http://deb.debian.org/debian trixie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list
sudo apt update
sudo apt install -t trixie-backports linux-image-amd64

Después de cualquiera de estos cambios, reinicie y confirme la versión con uname -r y el grep anteriores. Un kernel nuevo no se puede cargar dinámicamente: el parcheo dinámico del kernel en un VPS reemplaza el código de funciones individuales del kernel en ejecución, pero no puede cambiar las disposiciones de las estructuras ni añadir archivos de debugfs. La planificación consciente de la caché hace ambas cosas, porque añade campos a mm_struct. Por eso sólo llega al arrancar un kernel nuevo.

Hay dos tareas prácticas adicionales. Mantenga el kernel anterior disponible para el arranque hasta que el nuevo haya soportado su carga durante un tiempo. Para eso sirve fijar el kernel que arranca en un VPS. También debe vigilar /boot, porque la partición de arranque de un VPS pequeño se llena después de varias actualizaciones del kernel, como se explica en limpiar kernels antiguos en Ubuntu.

Hay un último aspecto importante sobre la responsabilidad. En un VPS KVM, el kernel invitado es suyo: usted lo elige, lo arranca y lo revierte. El kernel del host pertenece a su proveedor, y ninguna configuración dentro del sistema invitado cambia el planificador que ejecuta el hipervisor. Por tanto, una nota de la versión sobre la colocación del planificador sólo explica la mitad de la situación para un usuario. La mitad que usted controla es la del sistema invitado.

Fuentes utilizadas para esta página

• El resumen de cambios de 7.2 en kernelnewbies.org, para la fecha de publicación del 16 de agosto de 2026 y los cambios no relacionados con el planificador.
• La cobertura de LWN sobre la serie de planificación con conocimiento de la caché en lwn.net/Articles/1041668 y lwn.net/Articles/1058288, para los parámetros ajustables de debugfs, el mecanismo de preferencias por proceso y las cifras de rendimiento publicadas.
• El parche que condiciona la función a la topología, "sched/cache: Introduce sched_cache_present", para la regla según la cual el equilibrio de carga con conocimiento de la caché requiere más de una LLC en un nodo NUMA.

Para consultar la versión anterior, vea qué cambió en Linux kernel 7.1. Para saber cómo se obtuvieron los números de versión, consulte la cronología del historial de Linux kernel.

FAQ

¿La planificación consciente de la caché en Linux 7.2 hace más rápido un VPS?

Normalmente no por sí sola. La función sólo se activa cuando un nodo NUMA informa de más de una caché de último nivel, y un invitado KVM típico no muestra esa topología, por lo que el código nunca se activa. Cuando sí se activa, el invitado sigue teniendo dos niveles de planificación: el kernel invitado selecciona una vCPU y el kernel del host decide en qué núcleo físico se ejecuta el hilo de esa vCPU. Por tanto, el host puede anular la decisión de caché del invitado. Ejecute cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u en el invitado. Una sola línea que cubre todas las vCPU indica que no hay nada que la función pueda organizar.

¿Cómo compruebo si mi kernel tiene CONFIG_SCHED_CACHE?

Ejecute grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r). CONFIG_SCHED_CACHE=y significa que está integrado en el kernel; # CONFIG_SCHED_CACHE is not set significa que la distribución lo deshabilitó, y ninguna salida significa que el kernel es anterior a esta opción. Si la imagen no tiene el archivo /boot/config-*, pruebe con zcat /proc/config.gz, que sólo existe en kernels compilados con CONFIG_IKCONFIG_PROC. Puede confirmarlo en tiempo de ejecución con sudo ls /sys/kernel/debug/sched/ | grep -i llc, que muestra los parámetros llc_* cuando la función está disponible.

¿Cómo desactivo la planificación consciente de la caché sin reiniciar?

Escriba 0 en el parámetro de tolerancia: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. Esto desactiva la función en tiempo de ejecución y permite usarla como un interruptor A/B limpio para una prueba de rendimiento. Lea primero el valor actual con sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance y vuelva a escribirlo después, porque los valores predeterminados varían entre compilaciones. Ningún valor escrito en debugfs sobrevive a un reinicio. Si cat informa No such file or directory, el kernel no tiene la función compilada y no hay nada que desactivar.

¿Cuándo publicarán Ubuntu o Debian un kernel basado en 7.2?

Fedora adapta sus versiones estables a kernels mainline nuevos, por lo que llega primero mediante un dnf upgrade normal y un reinicio. Ubuntu publica kernels nuevos con cada versión semestral y los incorpora a la versión LTS anterior mediante la pila HWE. El desfase histórico se acerca a un año: en agosto de 2026, la pila HWE de Ubuntu 24.04 LTS usa 6.17, publicado en febrero de 2026, mientras que su kernel GA sigue siendo 6.8. Debian stable mantiene un kernel durante toda la versión y ofrece kernels más nuevos mediante trixie-backports, que se instala como paquete con apt install -t trixie-backports linux-image-amd64.