Linux Sin Humo

Archivos sparse en Linux

sebelk — Fri, 10 Jul 2026 10:00:00 GMT

Sparse files en la práctica

Un sparse file se entiende creándolo y mirándolo, no leyendo sobre él. Vamos a tratar un archivo como el disco de una máquina virtual: se crea a tamaño completo y el guest le escribe encima. En la terminal, esas escrituras las simulamos con dd.

El "disco" de 1 GiB, todavía en blanco:

truncate -s 1G disk.img

Lo medimos de dos maneras —lo que declara y lo que ocupa de verdad—:

du -h --apparent-size disk.img    # 1,0G  ← lo que declara
du -h disk.img                    # 0     ← lo que ocupa

Declara un gigabyte y ocupa cero. Escribimos 16 MiB al principio, como el guest grabando su arranque:

dd if=/dev/urandom of=disk.img bs=1M count=16 seek=0 conv=notrunc status=none

du -h --apparent-size disk.img    # 1,0G
du -h disk.img                    # 16M

El tamaño declarado no se movió; el real subió los 16 MiB exactos que escribimos. Ahora otros 16 MiB, pero lejos, en el offset 512 MiB:

dd if=/dev/urandom of=disk.img bs=1M count=16 seek=512 conv=notrunc status=none

du -h disk.img                    # 32M

Real 32 MiB, aparente todavía 1 GiB. Esos 32 MiB reales son solo las dos zonas de 16 que escribimos; entre ellas quedó un agujero de casi 500 MiB —espacio que el archivo declara pero para el que nunca se pidió un bloque en disco—.

Ahora al derecho y al revés. Llenamos parte del agujero, 128 MiB en el offset 200 MiB:

dd if=/dev/urandom of=disk.img bs=1M count=128 seek=200 conv=notrunc status=none

du -h disk.img                    # 160M

El real saltó a 160 MiB —los 32 de antes más los 128 nuevos—: escribir en un agujero cuesta disco. Y lo perforamos de vuelta, con fallocate:

fallocate --punch-hole --offset 200M --length 128M disk.img

du -h disk.img                    # 32M

El real volvió a 32 MiB: perforar libera los bloques y los devuelve al disco. Ese tramo, ahora vacío, se lee como ceros —no como basura, ni con error—:

dd if=disk.img bs=1M skip=200 count=128 status=none | tr -d '\0' | wc -c    # 0

En todo el recorrido el tamaño aparente no se movió de 1 GiB; el real subió al escribir y bajó al perforar. Son las dos medidas de un sparse file: lo que declara y lo que realmente ocupa en disco.

Las dos direcciones del recorrido, que es lo que conviene no confundir:

Operación	Partís de	Terminás en	`st_blocks`
escribir (`dd … seek=`)	agujero	datos en disco	sube
perforar (`--punch-hole`)	datos en disco	agujero (se lee como ceros)	baja

Perforar no escribe ceros: libera los bloques. Que el agujero se lea después como ceros es el efecto observable; el mecanismo es la desasignación, y por eso el espacio real baja en vez de subir.

Dos tamaños, no uno

El lab mostró dos números que se mueven por separado. Tienen nombre, y el inodo guarda los dos; stat los muestra juntos:

stat -c 'aparente=%s bytes | reales=%b bloques de %B bytes' disk.img

st_size (el "aparente") es el offset del último byte del archivo más uno. Es lo que responde ls -l. Es una declaración sobre el espacio de direcciones lógico del archivo.
st_blocks (el "real") es el espacio que el archivo ocupa de verdad, contado —en Linux— en unidades fijas de 512 bytes. Es lo que informa du.

El mismo archivo, sus dos medidas: st_size declara 1 GiB —el ancho lógico completo—; st_blocks cuenta solo los dos bloques tocados. Entre los datos, agujeros: espacio declarado que no ocupa disco.

Un archivo denso cualquiera muestra las dos magnitudes juntas. /usr/bin/chmod mide 65920 bytes (st_size), pero en disco ocupa 69632: el filesystem asigna bloques enteros de 4096, y 65920 bytes necesitan 17 de esos bloques (17 × 4096 = 69632), con 3712 bytes del último reservados pero sin usar.¹ En un archivo denso lo asignado iguala o supera al tamaño.

Un sparse file es el caso opuesto: st_size mayor que el espacio asignado, y la diferencia son los agujeros que vimos abrirse y cerrarse en el lab.

De dónde salen en la práctica

Los agujeros no son una curiosidad de laboratorio. Aparecen solos, sin que nadie los pida, cada vez que un programa escribe lejos del principio del archivo o libera rangos intermedios:

Imágenes de disco de máquinas virtuales. Un disco raw de 100 GiB con 8 GiB usados es un sparse file. qcow2 hace lo suyo por encima, pero el archivo subyacente también lo es.
Bases de datos que preasignan un archivo grande y lo llenan de a poco.
Clientes de BitTorrent, que crean el archivo con su tamaño final y van completando piezas fuera de orden.
Core dumps, que no vuelcan las regiones de memoria sin mapear.
/var/log/lastlog, que usa el UID del usuario como posición dentro del archivo — el caso más didáctico de todos.

Los filesystems que un sysadmin corporativo tiene enfrente —ext4, XFS, btrfs— soportan agujeros. También tmpfs. FAT y exFAT no, y son justo los que aparecen en un pendrive o en la partición EFI: copiar un sparse file a uno de ellos lo escribe entero, porque el destino no tiene forma de representar los agujeros.

Ver dónde están los agujeros

Para ver dónde están los agujeros —qué rangos tienen datos y cuáles son hueco—, xfs_io (del paquete xfsprogs) los marca con hole. Se apoya en FIEMAP, un ioctl genérico del kernel que ext4, XFS y btrfs implementan por igual, así que, a pesar de su nombre, sirve en los tres.

xfs_io -c fiemap disk.img
  0: [0..32767]: …
  1: [32768..1048575]: hole
  2: [1048576..1081343]: …
  3: [1081344..2097151]: hole

La tercera columna —los offsets físicos en disco— la recorté con …: cambia según el filesystem y no aporta acá. Los rangos van en sectores de 512 bytes: los primeros 16 MiB ([0..32767]) tienen datos, el tramo [32768..1048575] es un hole, en el offset 512 MiB ([1048576..1081343]) están los otros 16 MiB, y el resto hasta el final es otro hole.

Hay un camino más de bajo nivel: los flags SEEK_HOLE y SEEK_DATA de lseek (desde Linux 3.1) saltan al próximo agujero o al próximo rango con datos sin leer el archivo entero. Es el mecanismo que usan por dentro las herramientas que preservan agujeros al copiar, y el que las separa de las que re-inflan.

Una advertencia sobre filefrag, que suele ser lo primero que uno prueba: su conteo (N extents found) mide fragmentación física, no agujeros, y se lee distinto según el filesystem —el mismo archivo con el mismo agujero da "1 extent" en XFS y "2" en btrfs—. Para ver agujeros, fiemap.

Convertir ceros en agujeros

En el lab abrimos agujeros con --punch-hole. La otra variante, --dig-holes, recupera espacio: toma un archivo que ya ocupa disco lleno de ceros —una copia que se infló, una imagen descargada sin sparse— y reemplaza esas secuencias de ceros por agujeros. Un archivo de 64 MiB escritos en cero ocupa 64 MiB reales; después, cero:

dd if=/dev/zero of=lleno.img bs=1M count=64 status=none
du -h lleno.img                   # 64M
fallocate --dig-holes lleno.img
du -h lleno.img                   # 0   (el aparente sigue en 64M)

Con --dig-holes se cierra el cuadro de las tres operaciones. --punch-hole y --dig-holes terminan igual —un agujero, st_blocks baja—, pero parten de cosas distintas:

Operación	Partís de	Terminás en	`st_blocks`
escribir ceros (`dd if=/dev/zero`)	agujero	ceros reales en disco	sube
perforar (`--punch-hole`)	datos en disco	agujero	baja
cavar (`--dig-holes`)	ceros reales en disco	agujero	baja

Escribir ceros y cavarlos son inversas: la primera los materializa en disco, la segunda los recupera. Perforar es el atajo cuando ni siquiera te importa qué había en el rango.

Cuándo se convierte en un problema

El diseño se sostiene mientras el archivo se quede quieto. El problema aparece cuando algo lo copia, porque una herramienta que lee a través de la API normal de bytes ve ceros, no agujeros. Si al escribir no vuelve a perforarlos, los materializa.

Con el disk.img de arriba —1 GiB aparente, 32 MiB reales—, copiado en RHEL 8 (XFS, coreutils 8.30):

Operación	Ocupación en destino
`cp disk.img destino`	64 MiB
`cp --sparse=never disk.img destino`	1 GiB
`cat disk.img > destino`	1 GiB
`tar cf plain.tar disk.img` y extraer	1 GiB (y el `.tar` pesa 1,1 GiB)
`tar cSf sparse.tar disk.img` y extraer	64 MiB (y el `.tar` pesa 33 MiB)
`rsync -a disk.img destino`	1 GiB
`rsync -aS disk.img destino`	64 MiB

Las cuatro que re-inflan —cp --sparse=never, cat, tar sin -S, rsync -a— llevan la copia a 1 GiB: materializan cada cero.² Las tres que preservan el sparse —cp a secas, tar -S, rsync -aS— dan 64 MiB. Que cp sin flags preserve ya es contraintuitivo: su default es --sparse=auto, detecta los agujeros del origen y los recrea; solo los pierde con --sparse=never o si el destino no los soporta.

Pero 64 MiB es el doble de los 32 del origen, y no es re-inflado: los agujeros están intactos (xfs_io -c fiemap destino los muestra igual), y ese doble es XFS reservando bloques de más al escribir (speculative preallocation). Es una reserva transitoria —XFS la reclama con el tiempo (el barredor de eofblocks) o bajo presión de espacio, y su tamaño depende de la opción de montaje allocsize y de la versión—, así que el número exacto puede no reproducirse igual en otro XFS. En ext4 o btrfs la misma copia da los 32 MiB exactos: es un rasgo de XFS, no de las herramientas.

tar sin -S infla también el archivo .tar. Produce uno de 1,1 GiB en lugar de los 33 MiB que ocupa con -S. Ese gigabyte de ceros viaja por la red, se escribe en la cinta o en el bucket, y recién se nota cuando el job de backup llena el volumen de destino.

Con gzip, bzip2 o xz la falla es más difícil de ver, porque un gigabyte de ceros comprime a casi nada. El .gz es minúsculo y todo parece correcto. El gunzip en el destino escribe el gigabyte completo, sin agujeros.

De las herramientas de transferencia, scp y sftp no tienen ninguna noción de agujeros. Tampoco git: el blob incluye todos los ceros. dd los re-infla salvo que le pases conv=sparse.

La regla que se deduce de la tabla

Si una herramienta ofrece un flag explícito de sparse —rsync -S, tar -S, dd conv=sparse, cp --sparse=always, restic restore --sparse, borg extract --sparse— es señal de que por defecto no lo hace, o de que su default es una heurística que conviene verificar. Las que ni siquiera ofrecen la opción re-inflan siempre.

En backup empresarial el patrón se repite: Bacula y Bareos manejan agujeros solo si activás la directiva Sparse = yes, que viene desactivada. restic y borg deduplican los ceros muy bien —el repositorio queda chico— pero la restauración los re-infla si no le pedís lo contrario.

Hay una excepción importante, para no exagerar el problema: el backup a nivel de imagen o de bloque no lee archivos, lee bloques asignados del dispositivo. Los agujeros no le representan un problema. El riesgo descrito acá aplica al backup y la restauración a nivel de archivo.

El origen nunca se queja: el espacio real de un sparse file es minúsculo. La medición que importa no es la del archivo que tenés, sino la del que vas a producir —el destino de la copia, el .tar que se sube, el volumen donde se restaura—. Un du -h contra un du -h --apparent-size en el origen te dice cuánto puede crecer; los flags de la herramienta te dicen si va a crecer.

Fuentes y más recursos

stat(3type) — define los campos de struct stat. Sobre st_blocks: "the number of blocks allocated to the file, in 512-byte units". El stat(2) advierte que esa unidad no es universal (HP-UX cuenta en 1024, AIX en 4K); en Linux es 512.
lseek(2) — define SEEK_HOLE y SEEK_DATA, el mecanismo que permite recorrer agujeros sin leer el archivo entero. Disponibles desde Linux 3.1.
fallocate(1) — --punch-hole para perforar un rango y --dig-holes para convertir en agujeros las secuencias de ceros ya escritas.
filefrag(8) — inspecciona el mapa de extents de un archivo; viene en e2fsprogs.
man 1 cp — la sección de --sparse aclara que la detección por defecto (auto) usa "un mecanismo heurístico muy básico": por eso conviene medir en lugar de asumir.
man 1 tar — -S/--sparse y --hole-detection=seek|raw, que usa SEEK_HOLE cuando puede y cae a leer el archivo crudo cuando no.
Restauración con restic — documenta que "By default, restic does not restore files as sparse"; hay que pasar --sparse.
borg extract — su opción --sparse recrea los agujeros a partir de los bloques de ceros.

Ese mismo espacio asignado lo expresa cada herramienta en su propia unidad, y los números no siempre coinciden: stat da st_blocks = 136 (136 × 512 = 69632), ls -ls pone 68 en su primera columna (68 × 1024 = 69632) y du dice 68K. La diferencia entre 136 y 68 es solo la unidad —512 bytes contra 1024, el default de GNU ls—. Con POSIXLY_CORRECT, o con ls -s --block-size=512, ls -s baja a 512 y coincide con st_blocks. ↩
En btrfs con compresión (el default de Fedora) esas cifras de 1 GiB salen mucho más chicas: los ceros reescritos se comprimen a casi nada. El archivo se re-infla igual en el espacio lógico, pero el filesystem disimula el costo en disco. ↩

Intel y AMD: quién fija el límite de potencia del CPU

sebelk — Tue, 23 Jun 2026 04:03:53 GMT

Hace unas semanas conté cómo limité térmicamente una notebook Intel usada como CPU box en clamshell —tapa cerrada, monitor portátil encima, la máquina debajo de todo—: Gestión térmica en notebook clamshell con RAPL y tuned. La idea era bajar a mano el techo de potencia para que el CPU no entrara en throttling (que no se frenara solo al recalentarse).

Cuando fui a repetir lo mismo en un equipo AMD Ryzen, el ejercicio derivó en algo más interesante que portar una receta. Intel y AMD no se diferencian solo en cómo se toca el límite: se diferencian en quién puede fijar el límite de la potencia y la frecuencia — el hardware solo, o también vos. Y esa diferencia, no el clamshell, es lo que vale la pena contar.

El clamshell quedó como lo que era: el escenario que me obligó a medir. Lo uso de banco de pruebas, pero el tema es la comparación.

Cómo controla Intel: el límite lo escribís vos

En Intel, el techo de potencia es algo que escribís vos. RAPL (Running Average Power Limit) expone dos límites de potencia: PL1, el techo sostenido que el chip mantiene en el tiempo, y PL2, uno más alto que se permite por ráfagas cortas (el boost). Viven en el powercap framework del kernel —la interfaz bajo /sys/class/powercap para poner topes de potencia— y son de lectura/escritura:

echo 12000000 | sudo tee /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw

Ese echo baja la potencia disponible y el PCU (Power Control Unit) del CPU la respeta. El hardware sigue teniendo su propia gestión térmica, pero ese tope es un control compartido: el sysadmin puede ponerlo por debajo del default de fábrica, y el procesador lo aplica.

Cómo controla AMD: el límite lo decide el firmware

En AMD ese control, sencillamente, no te lo dan. La rama de powercap puede existir —los Ryzen modernos exponen RAPL— pero con una diferencia decisiva:

En AMD, el RAPL del powercap reporta energía consumida (energy_uj), pero los archivos de límite de potencia (constraint_*_power_limit_uw) no se exponen. El máximo de potencia no se fija desde el sistema operativo.

No es un problema de permisos: el kernel no expone esa escritura para AMD por ninguna vía mainline (lo que viene de fábrica en el kernel oficial). Y hasta la lectura de energía está acotada: el energy_uj que aparece más abajo es legible solo por root desde el kernel 5.10, como mitigación de un ataque de canal lateral (PLATYPUS). Escritura del límite, en cambio, nunca hubo. El gobierno de la potencia y la frecuencia ocurre adentro del SMU (System Management Unit), el microcontrolador del SoC, que regula solo, en tiempo real, contra el primero de varios límites que se sature —potencia, corriente y temperatura—. El sistema operativo no hace esa regulación fina ni escribe el límite de potencia, pero tampoco es un espectador pasivo: le fija la política dentro de la cual optimizar —el gobernador, la preferencia de eficiencia o rendimiento (EPP) y el perfil de energía— y lee la telemetría.

Comprobalo en tu propia máquina. En vez de apuntar a un archivo puntual, listá el contenido de la zona del paquete y mirá qué hay:

cat /sys/class/powercap/intel-rapl:0/name
ls -l /sys/class/powercap/intel-rapl:0/

Dos cosas para notar. La primera: el dominio se llama intel-rapl aun en una máquina AMD. No es un error — el soporte RAPL de AMD se registra reusando el mismo framework y el mismo nombre que ya existía en el kernel. La segunda, y es el punto: en mi equipo Ryzen el name da package-0 y adentro solo hay energy_uj (el contador de energía consumida, de lectura). No existe ningún archivo constraint_* — ni constraint_0_power_limit_uw ni sus variantes. En un Intel, esa misma carpeta tendría los constraint_0_* (PL1) y constraint_1_* (PL2): los archivos donde se escribe el techo de potencia. En AMD el concepto de límite ni se expone. RAPL mide; no limita. Y es así por cómo está implementado el driver de AMD en mainline, no por una particularidad de este equipo —aunque no probé cada combinación de kernel y BIOS.

La evidencia: qué hace el firmware de AMD bajo carga

Medí el equipo AMD en clamshell y en AC —la condición real de un CPU box: tapa cerrada, en corriente, con un monitor de 14" apoyado encima bloqueando el aire— con un baseline en reposo y un stress de 20 minutos sostenidos (stress-ng --cpu 0), registrando temperatura de paquete (Tctl, el sensor que reporta AMD vía k10temp) y frecuencia.

En reposo, ~40 °C. Bajo carga, la temperatura sube despacio y se asienta cerca de 73 °C —todavía trepando muy de a poco al cabo de los 20 minutos—, mientras la frecuencia se mantiene alrededor de ~3,0 GHz toda la corrida, sin caídas abruptas:

22:59:54  temp=59.2°C  freq=3044.129MHz
23:05:30  temp=69.0°C  freq=3019.180MHz
23:10:25  temp=71.2°C  freq=3019.166MHz
23:19:42  temp=73.4°C  freq=3019.182MHz

Dos cosas para leer de ahí:

El firmware sostiene un punto de operación estable de ~3,0 GHz con todos los núcleos cargados, sin que nadie intervenga. No es un techo que le puse yo: scaling_max_freq estaba en el máximo de fábrica. Es el SMU manteniendo la frecuencia que la potencia disponible le permite sostener.
La temperatura se queda lejos de cualquier límite. 73 °C, lejos de su límite térmico —el Tjmax: la temperatura a la que el chip se frena o se apaga para no dañarse, del orden de 90–100 °C según el modelo de Ryzen—: margen de sobra. Y en 20 minutos no hubo una sola caída abrupta de frecuencia: el firmware regula y se queda quieto.

Qué significa la diferencia

Dos formas de repartir el control:

En Intel el control se reparte. El PCU regula, pero te deja escribir el techo de potencia en mainline (PL1/PL2): podés bajar el límite por debajo del default de fábrica y el procesador lo respeta. Queda compartido entre el hardware y vos. En el post Intel fijé PL1 bajo y tuned activo, y la frecuencia se sostuvo estable en clamshell — aunque, en realidad, apliqué las dos cosas juntas y no aislé cuánto aportó cada una.
En AMD el control queda en el firmware. El SMU regula de forma autónoma; el sistema operativo le marca una preferencia —hacia eficiencia o rendimiento, vía EPP y el perfil de energía— pero no le escribe el límite de potencia. Para ponerle un techo duro desde mainline, lo único que queda es la frecuencia (scaling_max_freq). Pero —y esto es lo que muestran las mediciones— el firmware ya está haciendo la regulación: en 20 minutos de carga sostuvo la frecuencia estable por su cuenta, sin que yo tocara nada.

De esto se sigue algo que va a contramano del reflejo de optimizar:

En este equipo AMD, bajar el techo de frecuencia no solo es innecesario (el firmware ya regula solo) — es contraproducente: le quitarías rendimiento que el chip podía sostener, sin ganar nada en seguridad térmica.

La receta de RAPL no se porta a AMD, y no solo porque la API sea distinta (el powercap de AMD solo expone telemetría, sin archivos de límite). Y el problema que la justificaba, en este hardware, tampoco existe: el firmware moderno de AMD gobierna el clamshell solo.

Si igual querés meter mano en AMD

Para cerrar, las dos vías reales y su estado:

Techo de frecuencia (scaling_max_freq, mainline). Es lo que el kernel te da, sin agregar nada, para ponerle un techo duro: un echo por core, persistible al boot (un profile de tuned o un service propio), sin tocar voltaje. Útil si tu equipo sí oscila o si querés sacrificar rendimiento a propósito por un equipo más fresco. Por lo que vimos, para seguridad térmica acá sobra.
El tope de potencia (PPT vía ryzenadj). Es la forma de llegar a ese tope del SMU desde el sistema —los límites que AMD llama PPT (Package Power Tracking, el tope de potencia del paquete) y STAPM (atado a la temperatura de la carcasa)— pero queda fuera de mainline: ryzenadj (LGPL-3.0) se compila a mano y necesita el módulo ryzen_smu (GPL-2.0), que vive out-of-tree —fuera del árbol del kernel— y hay que recompilar en cada actualización (eso lo automatiza DKMS), además de pelear con Secure Boot. Es libre y se usa en producción en handhelds (Bazzite, Steam Deck), pero es tooling de entusiasta, no de infraestructura. Y es justamente la prueba de la tesis: el control que Intel expone en mainline, en AMD hay que buscarlo fuera del árbol. Nada de esto es peligroso —es runtime, no flashea firmware, un reboot revierte todo— pero para un CPU box que tiene que comportarse como infraestructura, el costo no se justifica.

Contrastar la premisa y después medir

El reflejo sería asumir que el setup Intel se porta cambiando una ruta de /sys. Pero la premisa hay que contrastarla, y no es la misma en los dos fabricantes: en AMD el archivo para establecer un límite ni siquiera está. Contrastarla a tiempo es lo que evita el desvío siguiente —buscar la herramienta que sí escribe watts y terminar en ryzenadj con un módulo out-of-tree—. Y antes de salir a buscar esa herramienta, conviene medir: acá la medición mostró que no había nada que arreglar.

La diferencia de arquitectura entre Intel y AMD define si te toca intervenir o si el firmware ya lo hace.

Lo que me llevo

Intel y AMD difieren en quién escribe el límite de potencia: Intel te lo deja en mainline (RAPL r/w); AMD lo retiene en el SMU —desde el SO le marcás una preferencia (eficiencia o rendimiento) y leés energía, pero el tope no lo escribís—.
En AMD, el firmware sostiene una frecuencia estable por su cuenta (~3,0 GHz en 20 min de carga) y la temperatura se queda con margen de sobra respecto del Tjmax. Sin oscilación ni throttling.
En AMD el tope de potencia (PPT) no se escribe en mainline —solo con tooling out-of-tree (ryzenadj)—; en mainline tenés la política (EPP, perfil de energía) y un techo por la frecuencia (scaling_max_freq), pero no el límite de watts directo. Es la contracara exacta de lo que Intel expone de fábrica.
Antes de optimizar, medir: en este equipo, bajar el techo habría sido contraproducente.
tuned cruza sin cambios entre plataformas — solo cambia el driver de scaling debajo (amd_pstate en vez de intel_pstate).

Fuentes

Documentación oficial y mediciones en el propio equipo.

Documentación oficial

Framework powercap del kernel (RAPL, zonas, constraint_* de lectura/escritura en Intel): Power Capping Framework.
Driver amd-pstate y sus modos (active/EPP): amd-pstate CPU Performance Scaling Driver.
Restricción de energy_uj a root como mitigación de canal lateral: PLATYPUS y CVE-2020-12912.
ryzenadj (LGPL-3.0; PPT/STAPM; necesita el módulo ryzen_smu): FlyGoat/RyzenAdj. Módulo ryzen_smu (GPL-2.0, out-of-tree): leogx9r/ryzen_smu; para hardware reciente (Zen 5), forks activos como amkillam/ryzen_smu.
Uso de ryzenadj + ryzen_smu en handhelds (undervolt del Steam Deck, vía un service con config en /etc/default/ryzenadj): Bazzite.
Tjmax exacto por procesador (depende del modelo): especificaciones de AMD.

Verificado en el equipo

Que el powercap de AMD solo expone energy_uj y ningún constraint_*, y la jerarquía package-0/core: los comandos cat/ls sobre /sys/class/powercap/ que están en el cuerpo. El driver (amd-pstate-epp) y las palancas de política (EPP, platform_profile) se leen read-only de /sys/devices/system/cpu/cpufreq/ y /sys/firmware/acpi/.
Que el firmware sostiene la frecuencia sin intervención: baseline y stress de 20 minutos, reproducibles con stress-ng --cpu 0 y la lectura de Tctl (k10temp).

3 Power Tips + Power Link I12

sebelk — Mon, 08 Jun 2026 04:16:42 GMT

"GUI vs CLI" es un falso dilema. Antes que técnico, es cultural: hábitos, modos de trabajo y supersticiones que arrastramos quienes trabajamos en IT. La consola y la interfaz gráfica no se disputan el mismo lugar; resuelven problemas distintos y, bien usadas, se complementan.

Power Tip #1 Una imagen contra una tabla de sectores

Hay que redimensionar una partición con datos, y querés ver cómo queda el layout antes de escribir al disco.

La línea de comandos no te deja sin red: sgdisk o un playbook de Ansible pueden simular el cambio sin escribir al disco. El tema es cómo lo muestran: una tabla de números —alineación a sectores, espacio libre real, orden físico de las particiones— que hay que reconstruir de cabeza.

GParted o KDE Partition Manager muestran ese mismo estado final, pero dibujado:

gparted /dev/sdX

Cargan el layout, dejan encolar varias operaciones, y muestran el resultado antes de aplicarlo. El "Aplicar" recién dispara las llamadas reales al disco.

Cuando la operación es difícilmente reversible y conviene evaluar el estado de antemano, la GUI es un camino apropiado: no porque la CLI no pueda simular, sino porque entrega una imagen donde la consola entrega una tabla. Y eso no tiene que ver con el nivel del operador.

Power Tip #2 El clic no se copia de manera natural

Ajustaste una regla de firewall desde Cockpit, el servicio volvió, y treinta días después hay que replicarlo en otros 50 nodos.

El cambio se hizo en la web UI, no en una shell.

history | grep firewall-cmd

No aparece nada: no hay un comando para copiar.

firewall-cmd --permanent --add-service=https && firewall-cmd --reload

La CLI permite reproducir y adaptar; la GUI facilita hacerlo una sola vez.

Power Tip #3 Un comando contra el asistente de media docena de pantallas

Hay que crear el mismo private endpoint en dev, staging y prod, y en el Portal es un asistente de varias pantallas cada vez.

Resource group, región, sub-resource, VNet, subnet: cada pantalla es un clic y un punto donde el tercer entorno termina distinto del primero.
No hay forma de correr "lo mismo" dos veces: cada pasada se arma a mano de nuevo.

az network private-endpoint create --name pe-app --resource-group rg-prod \
  --vnet-name vnet-prod --subnet snet-data \
  --private-connection-resource-id "$sqlid" --group-id sqlServer \
  --connection-name pe-app-conn

La misma operación entra en una línea parametrizable: la repetís idéntica en cada entorno cambiando un par de variables. El patrón no es de Azure — aws y gcloud resuelven lo suyo igual.

Cuando la misma operación se repite entre entornos, el asistente visual es el cuello de botella, no la ayuda.

Power Link

"La IA provocará la inutilidad de la línea de comandos". ¿Será así? Mark Pesce —co-creador de VRML— sostiene en The Register justo lo contrario: AI has made the Command Line Interface more important and powerful than ever before. Su argumento es que las GUIs se volvieron tan recargadas que ni los agentes las operan bien, y la CLI reaparece como el terreno común entre humanos y máquinas. No hace falta estar de acuerdo en todo para que la pregunta quede flotando: ¿cuánto de lo que se grita en los medios y en las redes sociales vamos a tener que repensar?

Gestión térmica en notebook clamshell con RAPL y tuned

sebelk — Sat, 30 May 2026 22:56:08 GMT

Tapa cerrada, monitor portátil apoyado encima, notebook como CPU box debajo de todo: lo que se llama modo clamshell —la notebook cerrada como una almeja, usada solo como unidad de cómputo con monitor externo—. El objetivo: evitar que suba la temperatura dañando el hardware.

El problema, brevemente

Los notebooks toman aire por abajo y/o expulsan calor por arriba del teclado. Un monitor portátil apoyado en clamshell rompe ese flujo. Como no se puede recuperar la disipación sin tocar hardware, lo que queda es bajar voluntariamente el techo de potencia para que el CPU jamás llegue a temperaturas de throttling.

Mejor 12W tibios sostenidos que un loop entre 28W ardiendo y 5W throttleado.

Eso es todo. El resto del post es la pelea para implementarlo en Fedora 43 (el setup no cambió en Fedora 44).

Las tres palancas

Linux expone tres puntos donde tocar, y cada uno opera en un plano distinto del sistema:

RAPL (Running Average Power Limit). El CPU Intel se autoimpone límites de potencia: PL1 sostenido, PL2 boost. Están en /sys/class/powercap/intel-rapl/. Si los bajás, el CPU físicamente no puede consumir más. Es el techo duro, aplicado por el hardware del procesador (el PCU, Power Control Unit): no depende ni del scheduler ni del usuario.

tuned. Daemon de gestión de perfiles de energía. Desde Fedora 41 es el default del sistema (vía tuned-ppd), reemplazando a power-profiles-daemon. Maneja governor, EPP, runtime PM, sysctls, sysfs. No baja literalmente el consumo: configura los subsistemas del kernel para que ellos lo hagan. Opera en el plano de las políticas, no del hardware — por eso no se solapa con RAPL.

thermald. Reactivo: lee zonas térmicas y aplica medidas correctivas cuando se calienta. En este equipo nunca funcionó, y de eso también va el post.

RAPL, primer round

Bajar PL1 a 12W y PL2 a 20W es un echo a un archivo en /sys/:

echo 12000000 | sudo tee /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw

Tres segundos, listo. Después de verificar que el valor quedó aplicado y que las temperaturas en stress test caían a una zona razonable, vino la primera trampa con la que choco cada tanto y siempre me tomo unos minutos para acordarme:

/sys no persiste. Lo que escribís ahí desaparece al reboot.

Solución: un service unit propio (rapl-limits.service) que reaplica los valores al boot. Heredoc, daemon-reload, enable --now. Hecho.

thermald, el daemon zombi

Acá viene la parte que me costó descubrir.

Habilito thermald, escribo un /etc/thermald/thermal-conf.xml custom, lo arranco. systemctl status lo reporta activo. ps -ef | grep thermald muestra el proceso vivo. Todo bien.

Solo que no estaba haciendo absolutamente nada.

Días después, ya con el sistema funcionando bien y con thermald deshabilitado por sospechoso, abro journalctl -u thermald para confirmar la sospecha. Encuentro esto, mezclado entre los logs:

thermald[1010]: Thermal DTS: No coretemp sysfs found
thermald[1010]: Thermal DTS or hwmon: No Zones present Need to configure manually
thermald[1010]: XML zone: invalid sensor type x86_pkg_temp
thermald[1010]: Zone update failed: unable to bind

Una sola causa raíz, dos síntomas en el log:

No había un sensor térmico del CPU que descubrir. El módulo que expone la temperatura de paquete no estaba cargado (No coretemp sysfs found), así que thermald arrancó sin ninguna zona del CPU a la vista. Lo venía diciendo desde el primer boot del histórico, mucho antes de que yo empezara a tocar nada.
El invalid sensor type x86_pkg_temp no significa lo que parece. x86_pkg_temp es el nombre correcto del sensor de paquete; thermald no lo rechaza por schema. Resuelve el tipo en runtime contra los sensores que efectivamente descubrió, y como no había ninguno, la búsqueda volvió vacía y el bind falló. El mensaje dice "invalid type" pero quiere decir "no encontré un sensor de ese tipo en este sistema".

Resultado: el daemon arrancaba, intentaba bindear las zonas definidas en el XML, no encontraba el sensor, y se quedaba corriendo sin nada que monitorear. Vivo, ocupando memoria, sin función.

systemctl status te dice si systemd cree que el servicio está bien. No te dice si el servicio está haciendo lo que tiene que hacer. Para eso está journalctl.

Validación empírica

Antes de tomar la decisión final de desactivar thermald, corrí un baseline de 6 minutos midiendo Package temp y frecuencia, después un stress test de 6 minutos exactos midiendo lo mismo, y los comparé. Lo que vi fue lo que esperaba: con RAPL fijo en 12W y tuned manejando el resto en su profile balanced, las temperaturas se mantenían en una zona estable y la frecuencia se sostenía sin las caídas abruptas del clamshell sin tunear.

La pregunta que la medición respondía no era "¿thermald aporta?" — eso ya estaba contestado de antemano por los logs. Era la otra: "¿con solo RAPL+tuned alcanza para clamshell?". La respuesta fue sí, y eso permitió cerrar el setup con tranquilidad.

Estado final

tuned                 → active (profile balanced)
RAPL PL1=12W PL2=20W  → fijo vía rapl-limits.service
thermald              → disabled (no podía operar en este hardware)

Filosofía: un techo duro de potencia (RAPL), un orquestador de estado (tuned), nada reactivo encima. Tres piezas, ninguna pelea con la otra, todas debuggeables.

Una nota sobre cómo empecé

Originalmente armé el setup con tlp + RAPL, siguiendo una sugerencia de Claude (vía claude.ai) que asumía power-profiles-daemon como el daemon por defecto en Fedora. No contrasté la premisa. Cuando fui a verificarla, descubrí que desde Fedora 41 el default pasó a tuned (vía tuned-ppd), no PPD. Y para este escenario — clamshell estático, siempre AC, sin diferenciar AC/BAT, sin que tlp-rdw aporte nada — tlp no resolvía nada que tuned no resuelva. Migré. El post documenta el setup resultante, no el camino original.

La lección no es "no preguntarle a una IA". Es verificar la premisa que la IA está usando, no solo la recomendación que te entrega. Un asistente puede recomendar una herramienta correctamente condicional a un default que ya no es el actual; sin contrastar esa premisa, terminás con un setup más complicado del necesario.

Lo que me llevo

Un daemon puede estar "running" y no estar haciendo nada. La verdad está en los logs de aplicación, no en systemctl status.
Un unit file propio de pocas líneas a veces es la decisión correcta y que no requiere demasiado esfuerzo.
El consejo técnico de una IA puede ser internamente coherente y aún así basarse en premisas obsoletas (defaults, versiones, comandos). El costo de chequear la premisa antes de implementar es bajo; el costo de no hacerlo se paga cada vez que volvés a tocar el equipo.

3 Power Tips + Power Link I11

sebelk — Mon, 27 Apr 2026 16:57:09 GMT

Las PTs de este issue muestran cómo, incluso en la nube (en este caso Azure), siguen aplicando conceptos clásicos de sistemas: distinguir entre ejecución y estado, entender la irreversibilidad de ciertos valores (como secrets) y operar en ausencia de un mapeo explícito entre componentes. Al final, el progreso en la Estrategia de Innovación Abierta y Código Abierto en un estado alemán.

Power Tip #1 El exit code es local, no de Azure

El comando volvió con 0 y la app sigue cayéndose.

az reporta éxito al recibir el ACK del control plane.
El recurso queda en Updating o Creating por minutos.
El siguiente paso del script lo encuentra "no listo" y falla raro.

az resource show --ids "$id" --query "properties.provisioningState" -o tsv

provisioningState es un testigo más confiable del control plane.

Power Tip #2 El valor del secret se entrega una sola vez

La alerta de vencimiento de un secret se "resolvió" pero la app igual se cae.

credential reset devolvió el password en stdout.
Lo perdiste antes de guardarlo en el vault.
Entra ID considera el secret válido. Nadie puede usarlo.

az ad app credential reset --append ... --query password -o tsv

Si se perdió el valor generado, no se puede recuperar. Como perder una clave privada SSH: podés crear otra, pero no reconstruir la anterior.

Power Tip #3 El mapeo no vive donde uno espera

Sabés que la app usa un secret de un KV. No sabés cuál.

App Registration no declara qué KV la consume.
Key Vault no mantiene, por defecto, una relación nativa con la App Registration que originó el secret.
El nombre del secret en KV es convención del equipo responsable, no metadato de Azure.

for kv in $(az keyvault list --query "[].name" -o tsv); do
  az keyvault secret list --vault-name "$kv" \
    --query "[?contains(name, 'mi-superpower-app')].{kv:'$kv',name:name}" -o tsv
done

Si para rotar un secret tenés que salir a buscarlo, no está definido en ningún lado qué secret usa esa app...

Power Link

Este es un análisis del Open Source Observatory (OSOR) sobre la adopción de software Open Source en el estado alemán de Schleswig-Holstein. ¿Cómo les fue implementando LibreOffice, Thunderbird, and Linux?: From Early Adopter to Leader: Schleswig-Holstein's Open Source Evolution

3 Power Tips + Power Link I10

sebelk — Sat, 21 Feb 2026 16:57:09 GMT

Las herramientas de monitoreo son fundamentales, pero una pobre interpretación de los resultados, pueden llevar a conclusiones incorrectas. Incluso usando chatbots de IA, si hacemos preguntas deficientes podemos terminar girando en círculos o tardar más tiempo en resolver un problema. Lo mejor es reducir el nivel de especulación con hipótesis técnica. A continuación vemos unos ejemplos bien sencillos.

Power Tip #1

No todas las métricas que parecen similares describen el mismo fenómeno.

Aplicación lenta.
Load 15.
CPU idle 50%.

Alguien descarta CPU porque “está libre”.

Pero:

Load describe tareas en ejecución o esperando.
CPU usage describe tiempo ocupado.
CPU pressure describe tiempo en que las tareas no pudieron progresar.

Son fenómenos distintos.

Antes de interpretar, mirá comportamiento:

vmstat 1 5
mpstat 1

Y si necesitás otra capa:

cat /proc/pressure/cpu

Es importante saber que “Load no es necesariamente consumo de CPU”, sin embargo, más importante es entender qué está describiendo cada señal.

Interpretarlas como si hablaran de lo mismo es especulación con números.

Power Tip #2

Tomar una métrica aislada de memoria en Linux no implica entender como funciona

free -h

Las columnas están ahí. Pero entender qué representa cada una es otra cosa.

used no significa “memoria en crisis”.
buff/cache no significa “desperdicio”.
available no significa “memoria libre inmediata”.

Antes de reaccionar ante un número alto, mirá dinámica:

vmstat 1 5

Linux administra memoria como recurso dinámico, no como espacio estático.

Leer columnas sin entender el modelo del kernel es especulación con formato tabular.

Power Tip #3

Reiniciar en muchas situaciones no hace otra cosa que restaurar un estado. No explica causas.

El servicio falla.
Se reinicia.
Funciona.

Eso no es diagnóstico.

Antes de repetir el gesto automático:

journalctl -u servicio-problematico -n 50

Si no entendemos por qué se degradó, volverá a pasar.

Reiniciar elimina el síntoma. No valida la hipótesis. Las herramientas no están equivocadas.

La diferencia está en entender qué fenómeno describe cada señal. Está claro que en el mundo real, muchas veces determinar la causa del problema lleva más tiempo que usar un trigger que reinice un servicio. Algo que pasa muchas veces apps legacy (la falta de especialistas o la triste realidad de falta del código fuente). Sin embargo, el problema es cuando se usa esta metodologìa como primera opción...

Power Link

La IA terminará con las operaciones de IT. ¿En serio? Bueno, en realidad no, para sorpresa de tecno-optimistas o tecno-pesimistas, aquí hay un interesante análisis de Sebastián Martínez de SUSE sobre este tema: Why AI Still Cannot Run Your Linux Infrastructure (And What Must Change)

3 Power Tips + 1 Power Link I9

sebelk — Sun, 04 Jan 2026 18:30:54 GMT

PSI (Pressure Stall Information) permite observar ese tipo de situaciones y, sobre todo, cambiar la forma en que interpretamos problemas de rendimiento y estabilidad en Linux. A partir de esa señal, el foco deja de estar en métricas globales y pasa a decisiones concretas: entender dónde ocurre el problema, a quién afecta y cómo intervenir sin arrastrar todo el sistema. Finalmente, el Power Link nos lleva a ver qué opina Gaël Duval, el creador de la distribución Mandrake, sobre uno de los hypes actuales.

Power Tip #1: ¿Cómo se ven afectadas mis aplicaciones por falta de recursos?

Existe a veces una creencia basado en pensamiento mágico: que el monitoreo depende solamente de la herramienta que se utilice. Pero más que la herramienta lo importante, es qué se mide y cómo interpretar esos resultados. Las métricas más conocidas: uso de cpu, load-average, uso de memoria, uso de I/O, etc. si bien son útiles pueden darnos en muchos casos un panorama parcial. Eso sucede porque están basados en los recursos, o en el scheduler.

Existen sin embargo desde hace varios años métricas que están más centradas en como las aplicaciones se ven impactadas por el uso de recursos. Con PSI (Pressure Stall Information) obtenemos un indicio del tiempo que las aplicaciones quedan detenidas porque el sistema no puede darles CPU, memoria o acceso a disco en el momento en que lo necesitan.

Esto está expuesto en el sistema de archivos:

PSI distingue entre situaciones donde al menos una tarea queda bloqueada (some) y escenarios donde todas las tareas relevantes compiten por el mismo recurso (full). Valores elevados y sostenidos en este full caso suelen indicar un problema estructural: no de picos puntuales, sino de diseño, aislamiento o priorización de workloads.

Vale hacer aquí tres aclaraciones:

Esta funcionalidad está presente a partir de la versión 4.20 del kernel (RHEL8 la trae como backport). En algunas distribuciones puede ser necesario habilitar PSI explícitamente en el arranque.
Esta no es la métrica definitiva, sin embargo ignorarla es perder el cuadro completo de lo que sucede tanto en el sistema como nuestras aplicaciones.
Versiones recientes del kernel incluyen también la medición de la presión sobre irq.

Power Tip #2: Las disrupciones se pueden atribuir a workloads específicos

Cuando el host empieza a perder capacidad de respuesta, no siempre el problema es global. Es común que el sistema siga siendo usable mientras algunos servicios o aplicaciones comienzan a degradarse, simplemente porque no acceden a los recursos cuando los necesitan. Esa degradación suele manifestarse como lentitud, mayor latencia o pérdida de capacidad de interacción.

En un Linux moderno, el kernel organiza los procesos bajo dominios de control definidos por cgroups. Esto permite observar de forma localizada qué tareas empiezan a quedarse esperando recursos, en lugar de razonar únicamente a partir de métricas agregadas del host.

En sistemas basados en systemd, ese dominio no es abstracto: se corresponde con services, slices o scopes. El mismo síntoma que aparece a nivel global puede observarse dentro de estos límites, lo que permite atribuir dónde se generan las esperas, incluso cuando el resto del sistema continúa funcionando con normalidad.

Pensar a nivel host diluye el diagnóstico. En cambio poner el foco en en services, scopes y slices permite relacionar directamente los síntomas percibidos —lentitud, tiempos de respuesta, degradación de rendimiento— con un grupo de procesos concreto.

Es decir, uno puede decir que el host muestra la presión acumulada, pero los cgroups permiten entender qué se queda atascado y frente qué recurso.

Power Tip #3: Abordar el problema de manera localizada

Cuando un servicio o aplicación empieza a tener tiempos muertos o a interferir con el resto, tenemos varias maneras de abordar el problema. Y no estamos hablando de las típicas acciones: reiniciarlo, moverlo o rediseñarlo.

Podemos tomar medidas más estructurales, por ejemplo, crear un slice de systemd, establecer límites y luego confinar esos servicios o procesos en esos slices.

Sin embargo, antes de intervenir de manera prematura, es conveniente tener en cuenta que Linux, en general ya tiene una agrupación de slices, scopes y servicios bastante razonable. En este punto entonces, ya sabemos que ese servicio problemático ya corre dentro de un perímetro definido.

En lugar de crear un nuevo slice, que tiene un carácter más permanente, podemos adoptar una solución más sencilla y gradualista. En systemd, los parámetros que gobiernan cómo compite por recursos no están fijos en scopes o servicios.

Un vistazo rápido alcanza para verlo (los siguientes son ejemplos para entender la idea):

systemctl show -p ControlGroup,CPUWeight,MemoryMax,IOWeight procesos-ruidosos.scope

Y tomar cartas en el asunto:

systemctl set-property procesos-ruidosos.scope …

Ese tipo de intervención es local, reversible y no convierte un incidente puntual en un cambio estructural.

Intervenir sobre una unidad existente permite corregir interferencias concretas sin rediseñar el sistema ni propagar el problema.

Fuentes y más recursos

Qué son los cgroups y para qué sirven

Power Link

Gaël Duval, creador de Mandrake, Murena y e/OS reflexiona sobre el impacto de la AI en el software open source: Why AI won’t “Kill Open Source”

Plan Táctico y Estratégico de la Memoria en Linux

sebelk — Mon, 01 Dec 2025 05:00:32 GMT

La mitología en torno a la memoria en Linux ha producido una serie de relatos:

En un extremo: Linux puede funcionar con muy poca memoria RAM.
Del otro lado: Linux consume mucha memoria.
Y que una partición swap debe tener entre 1 a 2 veces la memoria RAM.

Como vemos, algunas historias son más recientes, otras más antiguas, pueden ser parcialmente ciertas y hasta contradictorias entre sí.

Este artículo tiene como propósitos:

Explicar de manera sencilla el funcionamiento de la memoria en Linux, desmitificando también algunos conceptos.
Enumerar y describir tácticas para que el uso de la memoria proporcione la mejor usabilidad y experiencia del usuario.
Ofrecer alternativas para que cada uno elija la mejor opción de acuerdo a sus necesidades.

Definiciones

Vamos a repasar algunos conceptos básicos que de manera más o menos frecuente usamos, usaremos metáforas en el camino. Ninguna metáfora es perfecta, sin embargo ellas nos ayudan a entender la realidad.

Memoria Virtual

La memoria virtual es el mecanismo por el cual cada proceso recibe un espacio de direcciones propio, independiente y protegido. El hardware traduce direcciones virtuales a físicas según tablas de páginas. Esto permite aislamiento, sobreasignación, mapeos de archivos y demanda dinámica de páginas, más allá de la cantidad de RAM disponible.

Linux trata de usar la mayor cantidad de memoria posible, para poder ejecutar las aplicaciones y acceder a los archivos de la manera más rápida posible. De manera que si la memoria libre es baja no es necesariamente un indicativo de un problema.

Page

Una página es la unidad mínima de memoria, de tamaño fijo (típicamente 4 KB), que el kernel y el hardware de gestión de memoria del procesador utilizan para organizar el espacio de direcciones y realizar el mapeo entre direcciones virtuales y físicas.

Page table

Es una estructura de datos jerárquica administrada por el kernel y usada por el hardware para traducir direcciones virtuales a direcciones físicas, con información de permisos y estado de cada página.

Page Fault

Un page fault ocurre cuando un proceso accede a una dirección válida de su espacio de memoria pero la página correspondiente no está preparada para ese acceso. Puede deberse a que la página aún no fue cargada, a que debe asignarse, o a que debe traerse desde disco. Si la página no está en RAM, el kernel debe cargarla, lo que puede ser lento; si ya estaba en RAM, el costo es menor.

Page cache

Es la caché de páginas de archivos gestionada por el kernel, usada para acelerar lecturas y escrituras almacenando en RAM los datos y metadatos de archivos y directorios, reduciendo accesos al disco.

Tipos de memoria

File Memory

Es la memoria relacionada con el Page Cache.

Anonymous Memory

Es la memoria que un proceso usa y que no está respaldada por un archivo: heap (asignada dinámicamente), stack (llamadas a funciones y almacenamiento de variables locales), COW (parte de la memoria cuando se crea un proceso hijo) y mapeos con MAP_ANONYMOUS. Su único respaldo posible es la swap. La memoria anónima se crea y utiliza en RAM. Si el kernel necesita expulsarla de RAM, su único destino posible es la swap, porque no tiene un archivo desde el cual reconstruirse. Pero su existencia normal no depende de la swap.

Memory Pressure

Memory pressure es un estado en el que las páginas libres caen por debajo de umbrales críticos, obligando al kernel a iniciar mecanismos de liberación de memoria.

En términos prácticos cuando la presión es alta pueden surgir ciertos síntomas:

Sitios web / servidores HTTP: La latencia aumenta porque los workers deben esperar a que el kernel libere páginas. Además, puede haber más CPU gastada en recuperar memoria, lo que degrada aún más los tiempos de respuesta.
Sistemas de escritorio: El sistema pierde fluidez porque el scheduler empieza a verse afectado por stalls debidos a las operaciones para liberar memoria y, si hay swap, el sistema puede entrar en swap thrashing. Esto produce lag del mouse, ventanas que tardan en responder, escritorios congelados por segundos, etc.
Acceso remoto (SSH, RDP, VNC): Al haber presión, las operaciones de usuario-espacio tardan más en ejecutarse, y los daemons pueden quedar brevemente estancados esperando memoria. Esto causa retrasos notables en la interacción remota.

¿Y qué sucede si la presión de memoria puede llegar a ser tan alta que el kernel ya no logra conseguir memoria ni siquiera después de intentar liberarla?

Thrashing

El thrashing ocurre cuando la memoria RAM no alcanza para mantener las páginas que los procesos usan todo el tiempo. El kernel empieza a sacar páginas de memoria para hacer lugar a otras nuevas, pero enseguida vuelve a necesitarlas. Esto genera un bucle de fallos de página y de recarga constante desde el disco.

Con swap: las páginas anónimas van y vienen entre RAM y swap, lo que dispara el uso de disco y vuelve el sistema extremadamente lento.
Sin swap: las páginas anónimas no tienen adónde ir y el kernel termina activando el OOM killer.
Incluso sin swap: puede haber thrashing si las páginas vienen de archivos (page cache), ya que el kernel debe recargarlas una y otra vez.

OOM (Out-Of-Memory) 💀 🔥

Out-Of-Memory es una situación en la cual el kernel agotó todos los mecanismos para liberar memoria:

Liberar páginas del caché.
Mover páginas anónimas a la swap.
Compactar memoria.
Liberar memoria mediante kswapd.
Aplicación de políticas de cgroups (muy común al usar contenedores).

OOM killer

El OOM killer es el mecanismo que usa el kernel cuando ya no puede asignar más memoria, incluso después de intentar liberar todas las páginas que es posible descartar o mover fuera de la RAM. En esa situación crítica, el kernel calcula un puntaje para cada proceso (oom_score) y finaliza al que resulte más conveniente para recuperar memoria rápidamente y permitir que el sistema siga funcionando. Este comportamiento puede influenciarse ajustando oom_score_adj, que hace que un proceso sea más o menos propenso a ser elegido.

oom_score

Como ya se mencionó a cada proceso se le asigna un puntaje de acuerdo a distintos factores, cuanto más alto es, más susceptible es a ser terminado por OOM killer.

Y también, como dijimos mediante oom_score_adj podemos influir en el score de un proceso:

En versiones más recientes de las distribuciones existe el comando choom que permite ver y/o ajustar dicho valor.

Swap

Los usuarios ocasionales de Linux y aun muchos sysadmins tienen una idea negativa sobre "la swap". Simplificaciones extremas y conceptos anticuados la han convertido en la gran villana de la historia del sistema operativo.

Si comparamos a la memoria con un escritorio, sin swap podría lucir así:

Photo by Ashim D’Silva on Unsplash

Así que primero vamos a decir lo que no es:

No es la memoria virtual sino que forma parte de la técnica que realiza el sistema operativo para administrar la memoria.
No es un espacio de reserva ni un último recurso. Es un espacio complementario que sirve para liberar RAM.
No funciona como último recurso, pero el sistema operativo puede mover hacia la swap las páginas de memoria no usadas recientemente.
No es algo de lo que el sistema operativo pueda prescindir alegremente, aun cuando la cantidad de memoria RAM física sea grande. Quienes parecen haber inventado la pólvora, nos cuentan que es posible técnicamente que Linux funcione sin swap. Si bien es cierto, al carecer de swap, el kernel no tiene manera de mover páginas de memoria anónimas hacia el área de swap y liberar así RAM para procesos que la necesitan urgentemente.

Nuestro escritorio con swap:

Photo by Alexandru Acea (edited by me) on Unsplash

¿Los cajones de un escritorio los usamos cuando lo tenemos abarrotado de cosas? No, los usamos para guardar cosas que no son de alta prioridad. Aunque es cierto, si luego queremos usar esa tijera o aquel destornillador en algún momento requerirá un poco más de trabajo, tendremos que abrir el cajón, buscarlo, extraerlo, etc.

Ah, y la swap también sirve para hibernar, aunque honestamente no sé cuánta gente mantiene esa práctica.

Tuning

Ahora veremos diferentes tácticas que podemos usar para optimizar el uso de la memoria.

cgroupv2

cgroup es un mecanismo para organizar los procesos de manera jerárquica y distribuir los recursos del sistema a lo largo de la jerarquía en una manera controlada y configurada.

Un cgroup se compone de un núcleo que es responsable primariamente de organizar de manera jerárquica los procesos y controladores que comúnmente distribuyen un tipo específico de recurso del sistema a lo largo de la jerarquía.

En la versión 2 de cgroup un proceso no puede pertenecer a diferentes grupos para diferentes controladores. Si el proceso se une al grupo alfa, todos los controladores para alfa tomarán control de ese proceso.

Supongamos que queremos que los procesos de un cgroup (y sus grupos hijos) conserven su memoria y no sean los primeros en perderla cuando el sistema necesita liberar RAM. Para eso sirve el parámetro memory.low: mientras el uso de memoria del cgroup se mantenga por debajo de ese valor, el kernel evita quitarle páginas y prefiere reclamarlas de los otros cgroups que no están protegidos. Recién cuando ya no queda nada por reclamar en otro lado toca la memoria protegida.

Otro parámetro interesante para monitorear es memory.pressure. Tiene dos líneas, some y full, que registran cuánto tiempo hubo tareas demoradas por falta de memoria. Entonces si miramos el archivo /sys/fs/cgroup/user.slice/memory.pressure:

some avg10=0.00 avg60=0.13 avg300=0.12 total=1690238
full avg10=0.00 avg60=0.10 avg300=0.09 total=1394199

Significa que, dentro del grupo de control user.slice, en los últimos 10 segundos no hubo tareas afectadas por presión de memoria. Sin embargo, en el último minuto las tareas estuvieron bloqueadas un 0,13% del tiempo y un 0,12% en los últimos cinco minutos. El valor total indica que estas situaciones acumulan aproximadamente 1,7 segundos de espera. La segunda línea muestra las mismas métricas, pero aplicadas a los casos en que todas las tareas del grupo estuvieron simultáneamente afectadas por presión de memoria (full en lugar de some).

Es decir:

some → indica si un retraso afectó al menos una tarea.
full → indica si el retraso afectó a todo el cgroup simultáneamente.

zram

zram es por así decirlo, una manera cool de usar swap gracias a un módulo del kernel.

Photo by chuttersnap on Unsplash

En lugar de gastar espacio en un disco (sea rígido o sólido) usamos dispositivos de bloque en la propia RAM. Los bloques swapeados se guardan comprimidos. Estos discos virtuales son rápidos y ahorran memoria.

Una de las pocas desventajas que tiene esta metodología es la incapacidad para poder hibernar el sistema operativo, al no estar presente la partición en un almacenamiento de tipo persistente.

EarlyOOM

El OOM killer del kernel solamente se dispara en situaciones extremas y le puede llevar mucho tiempo hasta que puede enviar SIGKILL a los procesos que sean necesarios para poder liberar memoria. Durante ese tiempo probablemente el usuario no pueda interactuar con el sistema operativo.

EarlyOOM trabaja en espacio de usuario y por lo tanto se puede anticipar y ser mucho más rápido.

El comportamiento predeterminado en Fedora es que si tanto la RAM como la swap libre caen por debajo del 10%, EarlyOOM le envía una señal de terminación al proceso con el oom_score más alto. Si la RAM como swap libre bajan por debajo del 5%, EarlyOOM le enviará una señal para matar a ese proceso, el de oom_score más elevado.

La idea es recuperar la usabilidad (especialmente en un entorno de escritorio) lo antes posible.

El problema es que EarlyOOM no soporta al momento la medición de la memory pressure como indicativo para tomar decisiones.

nohang

Este servicio es mucho más configurable y aporta una mejor solución que EarlyOOM.

Algunas funcionalidades son:

Se puede elegir la acción que realizará en una situación OOM.
Ofrece varios criterios para elegir los procesos a finalizar.
Soporta zram
Puede usar memory pressure para tomar una acción.
El archivo de configuración es medianamente sencillo

Sin embargo, este proyecto en la actualidad tiene poca actividad comparado por ejemplo con EarlyOOM

zswap

Con zswap no reemplazamos el espacio swap en el disco sino que usamos un caché comprimido en la RAM. Este método ahorra I/O, obteniendo entonces mejor rendimiento y alargando la vida útil de discos flash o sólidos. La única desventaja es usar algo de tiempo del procesador para realizar la compresión.

Photo by Pineapple Supply Co. on Unsplash

Mediante el caché se logra una diferenciación entre páginas más usadas (zswap) y menos usadas (swap).

systemd-oomd

El servicio systemd-oomd es un proyecto en el que comenzó en Facebook para integrarlo con systemd. En un principio estaba pensado para manejo de memoria a gran escala, y bastante más complejo de configurar. Sin embargo ha sido adoptado desde Fedora 34 reemplazando a EarlyOOM. En las distribuciones que usan versiones recientes de systemd, está disponible, aunque no todas lo habilitan de manera predeterminada.

Resumen

Swap no es la villana de la película
El tuning de cgroupv2 puede traer grandes beneficios, no obstante existen proyectos y distribuciones que no lo usan.
EarlyOOM es una solución rápida y aplicable a una amplia gama de sistemas Linux, aunque no siempre es la más exacta ni más elegante.
El servicio nohang (o nohang-desktop) es una opción más madura aunque algo más compleja que EarlyOOM, pero que sin embargo ha caído en cierta inactividad.
El servicio systemd-oomd inicialmente incorporado por Facebook es seguramente la opción más adecuada para escenarios más complejos y de manejo de memoria a gran escala. También es utilizado actualmente en sistemas de escritorio.
Sin embargo, muchas distribuciones o sabores de distribuciones prefieren usar el mecanismo clásico de OOM killer.
A veces se sugiere el ajuste de parámetros del kernel mediante sysctl.
Si se desea ahorrar espacio en disco se puede reemplazar la swap por zram, sacrificando la opción de hibernar el sistema.
La opción zswap es más sofisticada, aunque dependemos del uso de swap en disco.

Photo by sk on Unsplash

Fuentes consultadas

3 Power Tips + 1 Power Link I8

sebelk — Sun, 23 Nov 2025 22:09:59 GMT

Resumen: En esta entrega, un ejemplo del poder que tienen la subshells de bash, como solucionar problemas de SELinux con Podman, y el uso de la herramienta yq para procesar archivos yaml.

Nota: En los ejemplos de comandos el prompt del usuario no privilegiado es "$", mientras que el del superusuario es "#"

Power Tip #1: Crear entornos de bash efímeros usando subshells

Una subshell es una copia del proceso de la shell actual. Una manera de crear una subshell es usando () y sirve: para personalizar el entorno de bash de manera reversible. Por ejemplo, podemos cambiar de directorio y la variable de entorno C (POSIX) para que muestre los mensajes de salida y de error en inglés:

$ echo "$LANG"
es_AR.UTF-8
$ pwd
/home/sergio

Ahora creamos una subshell:

$ (LANG=C; echo "La variable LANG cambia a  $LANG"; cd /algun_dir || cd /tmp ; echo "el directorio actual es $PWD";  myscript.sh)
La variable LANG cambia a  C
-bash: cd: /algun_dir: No such file or directory
el directorio actual es /tmp
-bash: myscript.sh: command not found

Al terminar la subshell, volvemos a la shell madre y tanto el directorio de trabajo como la variable LANG, vuelven a sus valores predeterminados:

$ pwd
/home/sergio
$ echo "$LANG"
es_AR.UTF-8

Power Tip #2: Identificar y solucionar problemas de SELinux al usar volúmenes.

Supongamos que necesitamos probar una configuración en un contenedor:

$ podman run  --name mynginx  -d -v $HOME/sandbox/nginx.conf:/etc/nginx/nginx.conf --pull=never docker.io/library/nginx@sha256:553f64aecdc31b5bf944521731cd70e35da4faed96b2b7548a3d8e2598c52a42

Ahora bien: ¿Qué sucede si el contenedor en realidad, falla al arrancar como lo muestran los logs?:

$ podman logs mynginx 
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2025/11/24 20:09:21 [emerg] 1#1: open() "/etc/nginx/nginx.conf" failed (13: Permission denied)
nginx: [emerg] open() "/etc/nginx/nginx.conf" failed (13: Permission denied)

Si estás tentado a desactivar SELinux, te recomiendo enfáticamente que leas ¿SELinux? Nah, dejalo en Disabled. Lo que ocurre es que no hay ninguna regla que permita que el contenedor acceda al contexto del archivo nginx.conf del host.

Contexto del archivo:

$ ls -Z  $HOME/sandbox/nginx.conf
unconfined_u:object_r:user_home_t:s0 /home/sergio/sandbox/nginx.conf

Este problema se soluciona fácilmente:

podman stop mynginx
podman rm mynginx

Y ahora el contenedor arrancará sin inconvenientes:

podman ps
CONTAINER ID  IMAGE                                                                                            COMMAND               CREATED         STATUS         PORTS       NAMES
a29c08eda1b1  docker.io/library/nginx@sha256:553f64aecdc31b5bf944521731cd70e35da4faed96b2b7548a3d8e2598c52a42  nginx -g daemon o...  12 seconds ago  Up 12 seconds              mynginx
podman logs mynginx 
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2025/11/24 21:16:10 [notice] 1#1: using the "epoll" event method
2025/11/24 21:16:10 [notice] 1#1: nginx/1.29.3
2025/11/24 21:16:10y [notice] 1#1: built by gcc 14.2.0 (Debian 14.2.0-19) 
2025/11/24 21:16:10 [notice] 1#1: OS: Linux 4.18.0-553.84.1.el8_10.x86_64
2025/11/24 21:16:10 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 262144:262144
2025/11/24 21:16:10 [notice] 1#1: start worker processes
2025/11/24 21:16:10 [notice] 1#1: start worker process 28
2025/11/24 21:16:10 [notice] 1#1: start worker process 29

Ahora bien, la opción :Z no es mágica, para tener una aproximación a lo que hace veamos el contexto del archivo $HOME/sandbox/nginx.conf:

$ ls -Z  $HOME/sandbox/nginx.conf
system_u:object_r:container_file_t:s0:c369,c839 /home/sergio/sandbox/nginx.conf

Campo	Antes	Después	Comentario
Usuario (SELinux)	unconfined_u	system_u	Pasa de ser un usuario sin restricciones a un usuario gestionado por el sistema
Rol (SELinux)	object_r	object_r	Se mantiene sin cambios
Asignación basada en tipos	user_home_t	container_file_t	Cambia a un tipo de asignación en la cual los contenedores pueden escribir
Rango (SELinux)	s0	s0:c369,c839	Este cambio implica que solamente podrá utilizarlo de manera exclusiva un único contenedor

Power Tip #3: Filtrar un archivo de template en formato yaml de Zabbix sin instalar absolutamente nada

Solamente necesitamos Podman, en el siguiente ejemplo estamos filtrando todos los triggers estáticos con nivel de severidad HIGH o DISASTER:

podman run --rm -v "${PWD}":/workdir:Z mikefarah/yq  '.zabbix_export.templates[].items[].triggers[] | select(.priority == "HIGH" or .priority == "DISASTER")| {"Trigger": .name}' template_db_mssql_agent2.yaml
Trigger: 'MSSQL: Percentage of the buffer cache efficiency is low'
Trigger: 'MSSQL: Page life expectancy is low'
Trigger: 'MSSQL: Percentage of work tables available from the work table cache is low'
Trigger: 'MSSQL: Service is unavailable'

Fuentes y más recursos

Power Link

El enlace de esta edición apunta a una entrevista a Linux Torvalds que gira en torno a la evolución del hardware, la IA y su impacto en el Linux y el desarrollo del kernel: Linus Torvalds — Talks about AI Hype, GPU Power, and Linux’s Future . En la actualidad cuestiones como la programación guiada por la intuición con la ayuda de chatbots debates importantes, no solamente en Linux sino en el ámbito IT en general.

3 Power Tips + 1 Power Link I7

sebelk — Tue, 04 Nov 2025 22:10:17 GMT

Resumen: Tips para bash, KDE Plasma y el uso del shell para cambiar entre ambientes de desarrollo. Además, en el Power Link, un artículo de Aaron P. MacSween, en el que discute el uso de AI scraping de sitios web usados de manera no consensuada para entrenar Modelos Extensos de Lenguaje (LLMs).

Power Tip #1: Agrupación de comandos en bash

El shell bash permite agrupar comandos, una funcionalidad tan sencilla como potente, por ejemplo:

{ dnf -y upgrade && systemctl restart httpd mariadb php-fpm ; } || echo "The final status is unsuccessful 🙁"

De esta manera si algunos de los dos comandos falla, mostrará un mensaje de error unificado.

Power Tip #2: Uso de cuadros de diálogos nativos de KDE Plasma en Firefox

Para hacerlo hay que abrir la url about:config y luego setear la preferencia widget.use-xdg-desktop-portal.file-picker en 1.

Esto se basa en el uso de XDG Portals que es un elemento de la arquitectura de entornos gráficos. Ellos proporcionan sandboxing, funcionalidad en entornos Wayland y lo que nos interesa en este caso: coherencia en la interfaz del usuario.

Antes 🤐	Después 😎️

Ah... usar la variable de entorno MOZ_USE_XDG_PORTAL no es la manera recomendada, más allá de lo que diga cierto chatbot...

Power Tip #3: [Flask + Linux]: Entornos Seguros usando solo la Shell

Problema Común

Ejecutar una app Flask con DEBUG=True en producción expone trazas de errores, rutas internas y detalles del stack que pueden ser explotados. Un sysadmin o devops con experiencia sabe que una práctica profesional es externalizar la configuración y usar el sistema operativo como interruptor de entorno.

Solución Basada en Linux + Flask

Usá la variable de entorno de Linux FLASK_ENV para alternar entre una configuración segura de Producción (config_prod.py) y una configuración orientada a Desarrollo (config_dev.py).

Archivo	Ajuste	Enfoque
`config_dev.py`	`DEBUG = True`	Depuración y agilidad.
`config_prod.py`	`DEBUG = False` (más `SECRET_KEY`)	Seguridad y Gestión de Secretos.

En config_prod.py, además de DEBUG = False, la clave secreta se carga desde el entorno con SECRET_KEY = os.environ.get('PROD_KEY') — así nunca queda hardcodeada en el repo.

Fragmento de app.py

import os
from flask import Flask
# Se importan las clases para un código robusto:
from config_dev import DevelopmentConfig 
from config_prod import ProductionConfig

app = Flask(__name__)

if os.environ.get('FLASK_ENV') == 'production':
    # Entorno PROD: Carga DEBUG=False
    app.config.from_object(ProductionConfig) 
else:
    # Entorno DEV: Carga DEBUG=True por defecto
    app.config.from_object(DevelopmentConfig)

Control desde la Terminal

+--------------------------+----------------------------------------------------------------------------------+---------------------------------------------------+ | Entorno | Comando | Resultado | +==========================+==================================================================================+===================================================+ | Producción | export FLASK_ENV=production | Debug mode: off | | | | | | | python app.py | (modo seguro) | +--------------------------+----------------------------------------------------------------------------------+---------------------------------------------------+ | Desarrollo | unset FLASK_ENV | Debug mode: on | | | | | | | python app.py | (vuelve a depuración) | +--------------------------+----------------------------------------------------------------------------------+---------------------------------------------------+

✅ Conclusión:

Este patrón convierte tu shell de Linux en un switch seguro de entorno para tu app Flask.

Preguntas de repaso

Seguridad y DevOps (Power Tip #3): ¿Cuál es el riesgo principal de ejecutar una aplicación Flask con DEBUG=True en producción, y cómo permite la variable de entorno de Linux FLASK_ENV que el administrador (sysadmin o devops con experiencia) cambie de manera segura a la configuración de producción (config_prod.py) usando solo un comando en la shell?
Eficiencia en Bash (Power Tip #1): En el ejemplo de agrupación de comandos, ¿cuál es el propósito de encerrar las sentencias de actualización (dnf -y upgrade) y de reinicio de servicios (systemctl restart ...) entre llaves {}, y qué rol juega el operador lógico || en caso de que alguna de estas operaciones falle?
Experiencia de Usuario (Power Tip #2): Si un usuario de KDE Plasma desea que Firefox utilice los cuadros de diálogo nativos del escritorio en lugar de los predeterminados del navegador, ¿qué URL debe abrir y a qué valor debe establecer la preferencia widget.use-xdg-desktop-portal.file-picker?

Power Link

AI scrapers request commented scripts. ¿Hasta qué punto una actividad es considerada benigina cuando se entrenan LLMs? Y muchas cuestiones para pensar...