Si tienes un Ryzen y usas Linux, seguramente te ha pasado alguna vez que querías retocar los límites de consumo del procesador y la cosa se complicaba más de lo que debería: entrar a la BIOS, buscar el menú correcto, guardar, reiniciar y volver a probar. Ahora AMD plantea algo distinto, una interfaz oficial dentro del propio kernel. El ingeniero de AMD Shyam Sundar S K ha publicado en la lista de desarrollo de controladores de plataforma x86 una serie de parches para un controlador de overclocking de Ryzen en Linux que expone ajustes del firmware a través de sysfs, ese sistema de archivos virtual donde el kernel muestra los parámetros de los dispositivos como ficheros que puedes leer y escribir. Conviene decirlo desde el principio: son parches publicados para revisión, no algo que ya venga con tu kernel.
Qué puedes ajustar con el controlador AOD de AMD
El controlador se llama AOD, de AMD Overclocking, y funciona como una interfaz WMI hacia el firmware de la plataforma. WMI es el mecanismo por el que el firmware ofrece funciones al sistema operativo, y en este caso sirve para gestionar el overclocking y los límites de potencia y corriente de los Ryzen modernos. En su versión inicial, el controlador permite fijar mediante sysfs tres parámetros que cualquiera que haya trasteado con estos procesadores reconocerá enseguida.
El primero es el PPT, o Package Power Tracking, que marca la potencia máxima que puede consumir el procesador en conjunto. El segundo es el TDC, la corriente de diseño térmico, y el tercero el EDC, la corriente de diseño eléctrico. Dicho sin tecnicismos, entre los tres delimitan hasta dónde puede tirar de energía tu CPU, tanto de forma sostenida como en picos. Subirlos puede darte margen de rendimiento si tu refrigeración y tu placa lo aguantan, y bajarlos te sirve para lo contrario: un equipo más fresco, más silencioso o con menos consumo. Además de escribir esos valores, el controlador permite leer el rango que admite cada uno. Parece un detalle menor, pero es importante, porque en lugar de lanzar un número a ciegas puedes consultar primero qué límites acepta tu procesador. Es el tipo de cosa que separa un ajuste razonable de un experimento que acaba mal.
El interruptor de SMT y los relojes de memoria
Más allá de la potencia, el controlador añade dos funciones que merecen su propio comentario. La primera es el control de SMT, la tecnología que permite que cada núcleo físico ejecute dos hilos a la vez. Hasta ahora, la forma habitual de desactivarlo en Linux era pasar la opción nosmt al kernel, algo que se hace en el arranque y que apaga SMT desde el sistema operativo. Con esta interfaz se podría hacer a nivel de plataforma, es decir, desde el firmware, en lugar de desactivarlo solo en el kernel.
Esa diferencia no es puramente teórica. Hay quien desactiva SMT por seguridad, por estabilidad o porque cierta carga de trabajo rinde mejor sin él, y contar con una alternativa que no dependa del parámetro de arranque abre opciones. Aun así, el material publicado no entra en cuándo conviene una u otra vía, así que lo prudente es tratarlo como una posibilidad más y no como una sustitución automática. La segunda función es de lectura: el controlador permite consultar los relojes de memoria actuales. No los cambia, al menos en esta primera versión, pero tener ese dato disponible desde una interfaz oficial es una pieza más del rompecabezas. Si algún día se amplía, la base ya estaría puesta.
Cambios que esperan al reinicio y lo que queda por ver
Hay un detalle que te conviene tener presente si piensas en usarlo algún día: los ajustes de potencia no se aplican en tiempo real. Lo que escribas en sysfs entra en vigor en el siguiente reinicio. Esto cambia bastante la forma de trabajar, porque no vas a poder subir y bajar límites sobre la marcha mientras observas cómo reacciona el procesador. Tendrás que pensar el cambio, aplicarlo y reiniciar, un flujo más cercano al de la BIOS que al de una herramienta interactiva.
Por otro lado, lo que se ha conectado por ahora es solo una parte de lo que el firmware sabe hacer. El firmware admite muchos más comandos de los que este controlador expone en su forma inicial, y la esperanza, tal como se plantea, es que con el tiempo se vayan habilitando más controles. De momento nadie se compromete a nada: son parches en revisión, con las modificaciones y discusiones que suelen acompañar a cualquier propuesta de este tipo antes de que lleguen, si llegan, a una rama estable del kernel. Y aquí es donde conviene ser cauto. Que AMD publique código es una buena noticia para quienes usamos sus procesadores en Linux, pero un controlador inicial y modesto no equivale a una herramienta completa de overclocking. Dependerá de cómo evolucione la revisión, de cuántas funciones se vayan añadiendo y de cómo se integre todo con el resto de utilidades que ya usa la comunidad.
Lo más interesante, quizá, es el gesto en sí. Durante años, ajustar el hardware desde Linux ha dependido de ingeniería inversa, de herramientas hechas por la comunidad o de arrancar otro sistema operativo para tocar lo que hiciera falta. Que sea el propio fabricante quien proponga una puerta de entrada dentro del kernel no resuelve todos esos problemas, pero cambia el punto de partida. Habrá que ver si esta primera ventana se convierte en una puerta entera o se queda en una rendija, aunque incluso una rendija oficial tiene su valor cuando llevas tiempo mirando por la cerradura.
Añadir comentario
Comentarios