Linux Sin Humo (Publicaciones sobre power-management)

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).

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.