Evolución del Asignador de Memoria en Linux: De SLOB a SLUB_TINY y Más Allá
TL;DR — Lo que vas a tener al final
- Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
- Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
- Resultado: Servicio funcional y estable, documentado paso a paso.
- Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.
El asignador de memoria en Linux: una historia de tres siglas
Durante más de una década, el kernel de Linux ofreció tres asignadores de memoria en modo kernel: SLAB, SLUB y SLOB. Para un sysadmin que arranca un servidor hoy, SLUB es el único que importa — está activo por defecto en todas las distribuciones modernas y reemplazó al clásico SLAB hace años. SLOB siempre fue el patito feo: pequeño, simple y pensado para sistemas embebidos con muy poca RAM, donde cada byte cuenta.
El 2022, el mantenedor del subsistema de memoria, Andrew Morton, marcó SLOB como obsoleto. Un año después, en Linux 6.4, se eliminó del árbol principal. El hueco que dejó se llenó el mismo ciclo con una nueva opción de configuración llamada CONFIG_SLUB_TINY, pensada para los mismos casos de uso: sistemas embebidos con menos de 16 MB de RAM donde SLUB “completo” simplemente no cabe.
El 23 de septiembre de 2026, Vlastimil Babka, ingeniero de SUSE y uno de los mantenedores históricos del slab allocator, envió a la lista de correo del kernel ([PATCH RFC 0/8]) una serie de ocho parches que propone reemplazar CONFIG_SLUB_TINY por un parámetro de arranque llamado slab_tiny. Es un cambio pequeño en la superficie de uso pero interesante en su motivación: mientras “tiny” deja de ser una decisión de compilación, se vuelve una decisión de arranque. Esa diferencia abre un caso de uso importante que antes era imposible.
Qué cambia con el nuevo parámetro slab_tiny
El kernel de Linux ha usado siempre dos modelos para decidir cómo manejas la memoria: opciones de configuración que se eligen cuando compilas el kernel, y parámetros de arranque que se eligen cuando arrancas la máquina. Cada uno tiene sus trade-offs. Compilar es estático, más eficiente y permite optimizaciones específicas (dead code elimination, inlining en hot paths), pero inflexible. Arrancar es dinámico y permite elegir política según el caso, pero pierde las optimizaciones “gratis” del compilador.
La propuesta de Babka empuja CONFIG_SLUB_TINY desde el primer mundo al segundo:
| Aspecto | Antes (CONFIG_SLUB_TINY) | Después (parámetro slab_tiny) |
|---|---|---|
| Tipo de decisión | Compilación (Kconfig) | Arranque (boot param) |
| Flexibilidad | Una sola política por kernel | Mismo vmlinux, dos políticas |
| Optimizaciones de compilación | Sí (dead code, inlining) | Perdidas (menores) |
| Interacción con otras Kconfig | A veces incompatible | Eliminado por diseño |
| Estado | Activo | Deprecado (mantiene default) |
En resumen: slab_tiny haría lo mismo para sistemas embebidos, pero ahora se activa o se desactiva pasando el parámetro en la línea de arranque del kernel, sin recompilar.
Por qué importa: el caso kdump
Si nunca trabajaste con kdump, es uno de los mecanismos más útiles del kernel para diagnóstico post-mortem. Cuando un sistema Linux entra en panic, en lugar de simplemente colgarse, kdump captura el contenido de la memoria RAM en el momento exacto del fallo y lo guarda en un archivo llamado vmcore. Ese archivo después se analiza con crash para entender qué pasó.
El truco está en cómo se hace: hay un segundo kernel, llamado kdump kernel, que arranca apenas el primero entra en panic. Ese segundo kernel tiene que ser pequeño porque su memoria se pre-reserva del kernel de producción — es RAM que el kernel principal deja sin tocar para que esté disponible cuando falla. Cada byte desperdiciado en el kdump kernel es un byte menos disponible para el sistema corriendo.
Hoy, si quieres que el kdump kernel use un slab “tiny” para minimizar su footprint, necesitas compilar dos kernels diferentes — uno con CONFIG_SLUB_TINY=y para kdump, otro sin esa opción para producción. Eso duplica el trabajo de mantenimiento: dos configuraciones, dos imágenes, dos árboles de parches que mantener sincronizados.
Con slab_tiny como parámetro de arranque, la solución es elegante: un solo vmlinux, dos comportamientos según cómo se arranca:
# Kernel de producción: slab_tiny NO se pasa, comportamiento por defecto
linux /vmlinuz-7.4.0 root=/dev/sda1 ro quiet
# Kernel kdump: el mismo binario, arranca con slab_tiny activado
linux /vmlinuz-7.4.0 root=/dev/sda2 kdump_tiny=1 slab_tiny=1
irqpoll maxcpus=1 reset_devicesUna imagen, dos políticas. Esa es la killer feature de este rediseño, no la micro-optimización de RAM.
La serie de parches en detalle
El RFC enviado por Babka está dividido en ocho parches que aplican en orden. Cada uno refactoriza un aspecto específico del manejo del slab:
| Patch | Título | Función |
|---|---|---|
| 1/8 | refactor slab_min/max_order handling | Limpia el código de sizing previo al cambio |
| 2/8 | introduce slab_debug=N | Crea un modo debug que no hace checks, base para reusar paths |
| 3/8 | rework KMALLOC_RECLAIM handling of SLUB_TINY | Maneja separación reclaimable/no-reclaimable |
| 4/8 | make SLUB_TINY handling dynamic for sizing decisions | Convierte decisiones hardcoded a runtime |
| 5/8 | convert CONFIG_SLUB_TINY checks to kmem_cache_debug() | Reusa el infrastructure del slab_debug |
| 6/8 | remove remaining compile-time checks | Limpia los #ifdef restantes |
| 7/8 | add slab_tiny boot param | El patch central: registra el boot param |
| 8/8 | deprecate CONFIG_SLUB_TINY | Kconfig deprecated, mantiene solo como default |
Los números cuentan una historia clara: 132 líneas eliminadas y 120 añadidas, en nueve ficheros (mm/slub.c carga la mayor parte del cambio con 149 líneas modificadas). El refactor quita ifdefs densos que estaban atados a CONFIG_SLUB_TINY y los reemplaza por un único camino de código donde la decisión se toma en runtime consultando una variable booleana y un static key. Esto explica el segundo beneficio del cambio: el código se vuelve más simple y deja de tener interacciones sutiles con otras Kconfig que en el pasado rompían builds de distribuciones.
Lo que se preserva y lo que se pierde
No todo lo que hacía CONFIG_SLUB_TINY se puede mover a runtime. Algunas optimizaciones solo se pueden hacer cuando el compilador sabe de antemano que una rama de código nunca se va a tomar, así que desaparecen cuando esa decisión se vuelve dinámica. Babka las lista en el cover letter del RFC:
- Lo que se preserva (y es lo importante): el ahorro principal viene de desactivar el percpu object caching. En SLUB moderno, los sheaves por CPU mantienen un pool de objetos pre-asignados por cada CPU lógica. Sin ese pool, cada allocation va al slab shared, pero ahorras memoria por CPU. Eso es justo lo que necesitas en un sistema con poca RAM.
- Dead code elimination: cuando
CONFIG_SLUB_TINY=y, el compilador podía eliminar toda la rama de percpu caching. Con boot param, esa rama existe en el binario aunque esté inactiva. Memory savings menor. - Fast path inlining: el inlining agresivo en hot paths requiere visibilidad estática. Con boot param, ese inlining se pierde parcialmente. Impacto en performance leve.
- Merging de caches no-kmalloc-reclaimable y unreclaimable: tenerlas separadas ayuda a fragmentación de páginas de orden alto, no a footprint. Combinar las dos ahorra algunas structuras administrativas.
- Ignorar SLAB_NO_MERGE para performance: el flag existe para networking, donde caches separados pueden tener comportamientos distintos. CONFIG_SLUB_TINY lo ignoraba para ahorrar memoria.
El autor del RFC aclara que estos ahorros “perdidos” son relativamente menores comparados con el principal, que es desactivar el percpu caching. Si te importa SLUB_TINY por la RAM disponible (no por unas décimas de performance), el cambio es un net positive.
Qué puedes hacer hoy como sysadmin
El parámetro slab_tiny aún no está en ningún kernel estable: el RFC lleva cuatro días en la lista y todavía no hubo un pull request al mm tree. La ventana habitual de aceptación de un RFC grande como este suele ser 2-4 semanas de review, después al menos un merge window (los merge windows del kernel son cada ~10-12 semanas), así que el target realista es Linux 7.5 (después de 7.4 que ya está en rc).
Mientras tanto, si administras sistemas embebidos o tiny y quieres mantenerte al día con el refactor, hay tres cosas concretas que puedes hacer:
- Suscribirte al hilo del RFC. Si usas lore.kernel.org, sigue el cover letter en lore.kernel.org/lkml/20260923-slub_tiny_rework-v1-0. Las réplicas relevantes (especialmente la de Harry Yoo del 24-sep) muestran dónde está el debate abierto sobre si
slab_tiny=0debería ser válido. - Testear el patch en tu setup. Babka suele pedir benchmarks de will-it-scale (workloads mmap2 y process-fork) en réplicas de revisión. Si tienes tiempo y un sistema de prueba, tus números pueden acelerar la aceptación.
- Auditar tu Kconfig actual. Si tu kernel de producción usa
CONFIG_SLUB_TINY=y, documentalo en tu runbook. Cuando el cambio se acepte, vas a querer saber dónde estaba esa decisión y por qué, para migrar al boot param sin romper nada.
Si tu distribución mainline (Debian, Ubuntu, Fedora, RHEL, Arch) usa CONFIG_SLUB_TINY por defecto en alguna variante (algunas imágenes de rescate, imágenes ARM minimal, initramfs de sistemas poco potentes), estate atento a las release notes futuras: el default probablemente cambie a “desactivado” y se invite al usuario a pasar slab_tiny=1 explícitamente.
Lo que esto nos enseña sobre el kernel
Este tipo de refactor — reemplazar una decisión de compilación por una decisión de arranque — aparece en el kernel con más frecuencia de la que parece. La motivación suele ser la misma: ganar flexibilidad en casos de uso que el modelo compile-time no cubre. El kdump kernel es uno, pero hay otros:
- mitigaciones de Spectre/Meltdown: muchas se activan o desactivan vía boot param hoy, no Kconfig, precisamente porque el trade-off performance/seguridad depende del workload.
- Schedulers: puedes compilar con varios schedulers disponibles y elegir
sched_{eevdf,none}en arranque. - Mitigación de bugs CPU específicos: parámetros como
tsx=on|off,retbleed=off, todos son runtime por la misma razón: el mismo binario corre en hardware diferente.
El patrón se repite porque el modelo sirve. Y entenderlo ayuda a leer cualquier RFC futuro del mm tree sin perderse: cuando alguien propone convertir un Kconfig en boot param, casi siempre hay un caso de uso real detrás que el modelo compile-time no podía expresar.
Preguntas frecuentes
¿Por qué Evolución del Asignador de Memoria en Linux: De SLOB a SLUB_TINY y Más Allá es relevante para sysadmins Linux?
Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.
¿Qué necesito para empezar con Evolución del Asignador de Memoria?
Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.
¿Cuáles son los errores más comunes con Evolución del Asignador de Memoria?
Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.
¿Cuándo usar Evolución del Asignador de Memoria y cuándo una alternativa?
Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.
¿Cómo migro desde una configuración previa a Evolución del Asignador de Memoria?
Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.
Lee también
- Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
- Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
- Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
- Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
- Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux
