CPU Control: un Ryzen Master para Linux, de Zen 1 a Zen 5

Ryzen Master, la herramienta de AMD para vigilar y ajustar sus procesadores, solo existe para Windows. En Linux hay piezas sueltas —módulos del kernel, utilidades de línea de comandos—, pero nada que lo reúna todo con una interfaz cómoda y que además te diga qué es seguro tocar. Por eso existe CPU Control: monitor y ajuste de procesadores AMD Ryzen, nativo de Wayland (GTK4 + libadwaita), que funciona desde Zen 1 hasta Zen 5 y detecta qué permiten tu procesador, tu placa y tu BIOS.

Un vistazo a cada núcleo

La pantalla de Inicio muestra temperatura, reloj efectivo, potencia, corriente (TDC/EDC) y voltaje. Debajo, una tarjeta por núcleo agrupada por CCD/CCX, con su frecuencia, el uso de cada hilo, vatios, temperatura, voltaje y el valor de Curve Optimizer. La estrella marca el mejor núcleo según CPPC. También muestra la memoria y el FCLK y, como en GPU Control, qué límite está frenando al procesador.

Perfiles calculados para tu procesador, con un tope seguro

En Ajuste hay cuatro modos: Eco, Fábrica, PBO y Manual. Se pueden tocar los límites PPT, TDC y EDC, la temperatura, el escalar de PBO, el Curve Optimizer (para todos los núcleos o uno a uno), un OC manual con frecuencia y voltaje fijos, y lo de siempre en Linux: boost, EPP, gobernador y frecuencias mínima y máxima.

Lo interesante son los perfiles recomendados. Salen de una tabla con más de 50 Ryzen de escritorio (TDP, Tjmax, boost y límites de socket) y se recortan a un tope que depende de la placa, porque no es lo mismo el VRM de una A320 que el de una X570:

Así, un perfil como «Máximo PBO» simplemente no aparece si pasaría del tope de tu placa. El Curve Optimizer de los perfiles es prudente (−10 a −15 en Zen 3, −20 a −25 en Zen 4/5) y los dos mejores núcleos van 5 puntos menos agresivos, porque son los que más suben de frecuencia.

Un asistente de overclock que sobrevive a los cuelgues

El Asistente OC implementa la conocida guía de michaelnager en r/ryzen («Definitive Guide to Configuring Ryzen CPUs»):

1. Primero, la BIOS: valores por defecto, LLC del Vcore y del SoC en el segundo o tercer nivel, XMP activado y PBO desactivado. Si detecta una placa MSI, usa los nombres de sus menús.
2. Un voltaje fijo con tope: 1,30 V en Zen 2/3 y 1,20 V en Zen 4/5 (o un poco menos, para priorizar eficiencia).
3. Sube la frecuencia de todos los núcleos de 25 en 25 MHz y prueba cada paso con stress-ng --verify, cortando si la temperatura llega al tope.
4. Antes de cada paso guarda el estado en disco. Si el equipo se cuelga, al reiniciar marca esa frecuencia como fallida y propone la última estable, con 25 MHz de margen.

Diagnóstico: qué falta y qué no se puede

La pestaña Diagnóstico lista lo que falta instalar (con el comando exacto), lo que tu placa o tu BIOS no permite y qué funciones quedan activas en tu equipo. Por ejemplo, en una placa de la serie 300 con un Zen 3 avisa de que algunos fabricantes ocultan o bloquean PBO y Curve Optimizer, y recomienda valores moderados para su VRM de entrada.

Cómo funciona por dentro

Los ajustes de verdad (PBO, Curve Optimizer, OC manual) se hacen hablando con el SMU, el microcontrolador de gestión del procesador, a través del módulo ryzen_smu. Igual que en GPU Control, el trabajo está repartido para que lo mínimo corra como root:

Mi detalle favorito es cómo evita sustos: si no activas «Aplicar al iniciar», el perfil vive en /run y desaparece al reiniciar. Si un Curve Optimizer demasiado agresivo cuelga el equipo, basta con reiniciar para volver a la normalidad. Además, los valores de fábrica se capturan en cada arranque, «Restablecer de fábrica» deshace solo lo que cambió la app y, al volver de una suspensión, el perfil se vuelve a aplicar.

«Experimental» significa que esos comandos no tienen validación pública; hay que activarlos a propósito en Diagnóstico.

La revisión antes de publicarlo

Igual que con GPU Control, antes de publicarlo le hice con Claude Code una revisión de buenas prácticas centrada en la parte privilegiada:

• La parte root ignora las variables de entorno de prueba que permiten redirigir rutas en los tests: nadie puede usarlas para engañar al servicio.
• Servicio más aislado: su nivel de exposición en systemd bajó de 8,2 a 6,2. Dos opciones de aislamiento se dejaron fuera a propósito, porque podían afectar a lo que el servicio necesita leer del hardware.
• Código más legible: la detección de valores no válidos usa math.isfinite en lugar de la críptica comparación v == v.
• CSV: si no se puede crear el archivo, avisa en lugar de fallar.
• Las pruebas simulan un Ryzen 5 5500 (con y sin ryzen_smu), un 5950X, un 7800X3D y un SMU que rechaza el Curve Optimizer; todas pasan, igual que ruff.

Instalarlo

Está en github.com/1985a/cpu-control. En Arch Linux:

git clone https://github.com/1985a/cpu-control.git
cd cpu-control
makepkg -si
sudo systemctl enable --now cpu-control.service

# Módulo para PBO, Curve Optimizer y datos por núcleo
yay -S ryzen_smu-dkms-git
sudo modprobe ryzen_smu
echo ryzen_smu | sudo tee /etc/modules-load.d/ryzen_smu.conf

Sin ryzen_smu la app sigue funcionando como monitor y con los ajustes de cpufreq. Para voltaje, corriente y potencia en Zen 1–3 existe también zenpower3, y el asistente de OC necesita stress-ng. En sway conviene añadir:

# agente de contraseña (paquete polkit-gnome)
exec /usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1
# ventana flotante
for_window [app_id="org.cpucontrol.CpuControl"] floating enable, resize set 1280 860, move position center

Créditos

CPU Control se apoya en el trabajo de otros: los comandos del SMU, las direcciones de fusibles y la codificación del Curve Optimizer vienen de ZenStates-Core; la interfaz con el SMU es la de ryzen_smu, y los mapas de la tabla PM salen de ryzen_monitor_ng. Todos son GPL-3.0, y CPU Control también.

Ajustar voltajes y límites tiene riesgo. Usa valores moderados, sobre todo en placas con VRM de entrada (A320/B350/B450), y prueba la estabilidad antes de activar «Aplicar al iniciar». CPU Control es un proyecto independiente, sin relación con AMD.