- EPP es una pista de energía/rendimiento que la CPU usa para decidir si prioriza velocidad o eficiencia.
- Su valor se gestiona en sistemas modernos a través de drivers y sysfs como amd-pstate o cpufreq en Linux.
- Intel Meteor Lake, Emerald Rapids, AMD Zen y macOS XCPM aprovechan EPP para afinar turbo, consumo y temperaturas.
- Ajustar correctamente EPP y el modo de operación (activo, pasivo, guiado) mejora rendimiento por vatio y autonomía.
Cuando se habla de rendimiento y eficiencia energética en procesadores modernos, la sigla EPP (Energy Performance Preference) aparece cada vez más. No es un simple «modo rendimiento» o «modo ahorro», sino un mecanismo fino que indica al hardware qué priorizar en cada momento. Entender qué es EPP y cómo se usa marca la diferencia entre tener un portátil que vuela pero se bebe la batería, y uno equilibrado que aguanta horas sin renunciar demasiado a la potencia.
Además, esta preferencia energética se ha convertido en una pieza clave en Intel Meteor Lake, Xeon Emerald Rapids, AMD Zen con amd-pstate e incluso macOS XCPM. Los fabricantes de CPU y los desarrolladores del kernel de Linux la utilizan para exprimir cada vatio, tanto en portátiles como en servidores y sobremesas. Vamos a desgranar qué es exactamente EPP, cómo funciona por debajo, y qué implicaciones reales tiene en tu día a día.
Qué es EPP o Energy Performance Preference
En términos sencillos, EPP es una “pista” que el sistema operativo envía al procesador para indicarle si debe ser más agresivo buscando rendimiento o más conservador para ahorrar energía. No es una frecuencia fija ni un límite de potencia directo, sino una preferencia que el firmware y la lógica interna de la CPU interpretan para decidir cómo escalar frecuencias y voltajes.
En la práctica, el valor de EPP se expresa como un número de 0 a 255, donde un valor cercano a 0 significa «máximo rendimiento» y uno cercano a 255 se traduce en «máximo ahorro energético». Muchos sistemas lo exponen también como perfiles simbólicos como performance, balance_performance, balance_power o power, que internamente se corresponden con rangos numéricos dentro de ese 0-255.
Este concepto está estrechamente ligado a CPPC (Collaborative Processor Performance Control), un estándar ACPI mediante el cual el sistema operativo ya no ordena: «ponte en P-State 2» (tres estados fijos), sino que guía a la CPU con métricas continuas de rendimiento deseado, mínimos, máximos y preferencia energética.
Cómo funciona EPP a nivel de hardware y firmware
En procesadores modernos, especialmente en las arquitecturas recientes de AMD Zen y varias plataformas Intel, el control de frecuencia ya no se hace solo con escalado clásico de P-states. En su lugar, el kernel usa interfaces como amd-pstate o drivers específicos de Intel para escribir en registros CPPC y en ficheros expuestos vía sysfs.
La lógica suele seguir este esquema: el kernel calcula la carga de trabajo usando su planificador (schedutil, ondemand, etc.), decide un objetivo de rendimiento y luego aplica un EPP que indica si debe llegar rápido a la frecuencia máxima o hacer rampas más suaves para ahorrar energía. El firmware de la CPU, conociendo temperaturas, límites de potencia PL1 y PL2 y condiciones de silicio, traduce esa preferencia en una frecuencia efectiva.
En la documentación de AMD se detallan varios parámetros CPPC: Highest Performance, Nominal Performance, Lowest Non-linear Performance y Lowest Performance. A partir de estos puntos, el driver amd-pstate sabe cuál es el rango eficiente y cómo interactúa EPP con cada zona, de forma que por encima del rendimiento nominal se entra en zona de turbo sostenido y por debajo del punto no lineal se empiezan a conseguir ahorros de energía mucho más marcados.
EPP en Intel Meteor Lake: modos balanceados, rendimiento y ahorro
Con la llegada de Intel Meteor Lake a portátiles, una de las grandes promesas era precisamente mejorar la eficiencia frente a generaciones anteriores, sin perder competitividad ante las APU de AMD. Meteor Lake introduce una arquitectura en “Tiles” y nuevos mecanismos de gestión energética, donde el Energy Performance Preference tiene un papel protagonista.
En pruebas reales, como las realizadas sobre un Intel Core Ultra 7 155H bajo Linux, se han comparado los distintos modos EPP: perfil balanceado, perfil de rendimiento y perfil de ahorro de energía. Aunque el hardware es el mismo, cambiar el EPP altera tanto el rendimiento como el consumo, y no siempre el modo teóricamente «rápido» es el más eficiente.
Por ejemplo, en 3DMark Wild Life Extreme se observaron resultados llamativos: con el modo EPP balanceado se obtuvieron unos 91,35 FPS con un pico de 69 W, mientras que el modo rendimiento logró 87,67 FPS consumiendo hasta 82 W. Es decir, más consumo para menos rendimiento, probablemente porque el modo de rendimiento fuerce frecuencias altas antes de tiempo o mantenga voltajes elevados donde no compensa, penalizando la eficiencia térmica y energética.
El modo de ahorro de energía, por su parte, rondó los 80,93 FPS con un máximo de 63 W, sacrificando algo de potencia bruta a cambio de una caída notable de consumo. Este patrón se repite en otros benchmarks, mostrando que el equilibrio adecuado de EPP puede dar más FPS por vatio que simplemente empujar la CPU al límite.
Impacto del EPP en aplicaciones reales con Meteor Lake
Cuando se pasa de pruebas sintéticas a tareas de uso diario, el comportamiento de los modos de EPP sigue siendo muy relevante. En benchmarks de navegador como Selenium Jetstream 2 con Firefox, el modo rendimiento consigue aproximadamente un 10% más de puntuación que el modo balanceado, a cambio de pasar de unos 58 W a unos 63 W. Aquí la diferencia de consumo es relativamente contenida, y puede compensar si buscas la máxima fluidez en tareas de CPU ligera.
En cambio, el modo de ahorro de energía reduce el rendimiento prácticamente a la mitad, pero el consumo de la CPU baja a unos 20 W. La eficiencia por vatio se dispara: se habla de alrededor de 15.464 puntos por vatio frente a 8.555 en modo balanceado y 7.652 en modo rendimiento. En portátiles, esta mejora es oro puro si lo que interesa es autonomía.
En aplicaciones como GIMP, el modo ahorro hace que las tareas tarden casi el doble, porque la CPU limita su consumo a aproximadamente 18 W frente a los 44-53 W de los modos balanceado y de rendimiento. En Blender 4.0, curiosamente, el rendimiento apenas cambia entre modos, pero sí baja el consumo del modo ahorro en unos 10 W y la frecuencia máxima cae a unos 2,8 GHz, lo que demuestra que no todas las cargas responden igual al EPP.
Si se mira una batería más amplia de tests, se ve que el modo rendimiento solo supera al balanceado en torno a un 4% de puntuación global, pero a costa de un 22% más de consumo. Con medias de frecuencia de unos 3651 MHz en rendimiento, 3193 MHz en balanceado y 2414 MHz en ahorro, las temperaturas del modo ahorro se reducen hasta unos 8 ºC menos y el consumo medio se queda casi en la mitad. Esto deja claro que, con Meteor Lake, el EPP bien ajustado es casi más importante que el TDP nominal a la hora de afinar el comportamiento.
EPP en Intel Emerald Rapids: un simple valor que cambia el juego
En el segmento de servidores, el EPP también está demostrando ser determinante. En las CPU Intel Xeon Emerald Rapids, el valor por defecto del Energy Performance Preference en Linux se había configurado inicialmente en 128 para el modo Balance_Performance. Sin embargo, los desarrollos de kernel capitaneados por Rafael J. Wysocki, junto con análisis internos de Intel, demostraron que ese ajuste no era óptimo.
Tras pruebas comparativas, se vio que establecer el EPP para ese mismo modo en un valor de 32 proporcionaba una combinación mucho mejor de rendimiento y consumo. Con esta modificación se consiguieron mejoras significativas en varios escenarios típicos de servidor, manteniendo e incluso reduciendo ligeramente la energía consumida.
Los datos publicados muestran ejemplos claros: en POV-Ray se llegó a un 32% más de velocidad con un 12% menos de energía; en OpenSSL el rendimiento subió alrededor de un 12% con una reducción de consumo en torno al 1%; y al compilar el kernel de Linux se obtuvieron mejoras de cerca de un 29% de tiempo con un 18% menos de energía. Todo esto sin cambiar hardware, solo tocando un parámetro de EPP en el kernel.
Por ello, el kernel de Linux volverá a fijar el EPP por defecto para el modo Balance_Performance en 32 en las máquinas Emerald Rapids, alineándolo con lo que se usaba en Sapphire Rapids. Este ajuste llegará a los usuarios con Linux 6.11, por lo que las cargas de trabajo en centros de datos podrán beneficiarse sin necesidad de reconfigurar manualmente cada servidor.
EPP y Linux: sysfs, amd-pstate y acpi-cpufreq
En Linux, la interacción con EPP está muy asociada al subsistema cpufreq y a drivers específicos como amd-pstate o acpi-cpufreq. Cada CPU expone sus controles a través de ficheros en /sys, lo que permite ajustar preferencias a nivel de núcleo o de política.
Por ejemplo, en Ubuntu el valor de EPP de cada core se puede leer en /sys/devices/system/cpu/cpu#/cpufreq/energy_performance_preference. Ahí se ve la preferencia actual (por ejemplo, performance, balance_power, power, etc.). Para saber qué perfiles admite la CPU, se puede consultar /sys/devices/system/cpu/cpu#/cpufreq/energy_performance_available_preferences, donde se listan todas las opciones válidas.
Además de los valores simbólicos, muchos kernels permiten escribir directamente un valor numérico entre 0 y 255 en el fichero energy_performance_preference. Como se ha comentado antes, un número más cercano a 0 favorece el rendimiento agresivo, mientras que uno cercano a 255 inclina la balanza hacia la eficiencia energética. Esto permite un nivel de ajuste muy fino para usuarios avanzados.
El driver amd-pstate y la preferencia energética en CPUs AMD
En las CPU y APU modernas de AMD (Zen2 y superiores), el kernel Linux cuenta con un driver específico, amd-pstate, que sustituye al clásico acpi-cpufreq y aprovecha por completo la interfaz CPPC. En lugar de limitarse a tres P-states fijos, este driver ofrece un espectro continuo de rendimiento, manejando frecuencias y voltajes con gran precisión.
El driver amd-pstate se integra con los gobernadores genéricos de cpufreq como schedutil u ondemand. Estos calculan, en base a la carga de la CPU, qué rendimiento objetivo se requiere y el driver lo traduce en parámetros CPPC (mínimo, máximo, deseado y EPP). Con ello, la CPU puede ajustar en tiempo real su frecuencia para cumplir la demanda con el mínimo gasto energético posible.
Dentro de amd-pstate la preferencia energética se controla mediante EPP (Energy Performance Preference), y se expone a través de los mismos ficheros de sysfs mencionados antes: energy_performance_preference y energy_performance_available_preferences. Los perfiles habituales incluyen default, performance, balance_performance, balance_power y power, que se corresponden con distintos compromisos entre rapidez y ahorro.
Modos de operación de amd-pstate: activo, pasivo y guiado
El driver amd-pstate puede trabajar en tres modos, que se seleccionan con parámetros del kernel: amd_pstate=active, amd_pstate=passive y amd_pstate=guided. Cada modo define cómo se reparte la responsabilidad entre el sistema operativo y el firmware de la CPU.
En el modo pasivo (amd_pstate=passive), el kernel indica un nivel de rendimiento deseado relativo a la capacidad máxima del procesador. Por debajo de un punto, el rendimiento es medio; por encima, la CPU intenta mantener su mejor nivel dentro de sus límites térmicos y de potencia. El sistema operativo lleva más peso en la decisión del objetivo de rendimiento.
En el modo activo (amd_pstate=active), presentado junto con el driver amd_pstate_epp, se delega más control al firmware. El software envía sugerencias EPP (performance, balance_power, power, etc.) y el hardware decide las frecuencias con mayor autonomía. Esto permite que la CPU reaccione muy rápido a cambios de carga, ajustando internamente el turbo y el voltaje según la preferencia energética configurada.
El modo guiado (amd_pstate=guided) es un punto intermedio: el kernel fija un rango de mínimo y máximo rendimiento y la plataforma escoge automáticamente un punto dentro de ese rango, según la carga y las condiciones. De esta forma se combina la flexibilidad del firmware con las decisiones de alto nivel del sistema operativo.
Gestión práctica de EPP en sistemas AMD con Linux
En la práctica, para aprovechar amd-pstate y EPP en una CPU AMD compatible (por ejemplo, una APU Ryzen 7000 de portátil), suelen seguirse dos pasos: habilitar el modo deseado en la línea de arranque del kernel y ajustar los perfiles EPP vía sysfs.
Si se utiliza una distribución como Pop!_OS con kernelstub, se puede añadir el parámetro amd_pstate=active o amd_pstate=guided fácilmente. Tras reiniciar, se comprueba el driver activo con cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver, que debería devolver amd-pstate o amd-pstate-epp dependiendo del modo.
Una vez que el driver está en marcha, los ficheros /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference y /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_available_preferences permiten ver y cambiar la preferencia. Se puede, por ejemplo, aplicar «power» a todos los núcleos ejecutando un simple echo "power" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference, lo que hará que la CPU priorice al máximo el ahorro de energía.
Este cambio no es permanente, así que si se quiere mantener tras cada reinicio habrá que usar herramientas específicas de la distribución, servicios de systemd o un trabajo cron. Además, se debe tener en cuenta que el driver de escalado (amd-pstate) es independiente del gobernador de CPU (powersave, performance, schedutil, etc.), y ambas piezas se pueden combinar para afinar todavía más el comportamiento.
Relación entre EPP, X86PlatformPlugin y XCPM en macOS
En macOS, aunque el término EPP no se expone de forma tan directa al usuario como en Linux, el concepto subyacente está presente en el sistema de gestión de energía de la CPU, conocido como XCPM (XNU CPU Power Management). Apple utiliza kexts como X86PlatformPlugin para aplicar perfiles de energía y rendimiento dependiendo del modelo de CPU y del SMBIOS configurado, especialmente en el mundo Hackintosh.
Cuando X86PlatformPlugin está correctamente enganchado a AppleACPICPU en el IORegistry, macOS tiene acceso a datos de gestión de energía avanzados, incluyendo tablas de frecuencia y políticas que dictan cómo y cuándo acelerar o frenar el procesador. Herramientas como CPUFriend permiten modificar estas políticas, inyectando datos personalizados que ajustan, entre otras cosas, la rapidez con la que la CPU sube a máximas frecuencias y el comportamiento en reposo.
En ese contexto, uno de los parámetros que se manipulan es el equivalente funcional al EPP: valores que indican a macOS si debe favorecer una subida rápida de frecuencia (0x00, máximo rendimiento), un equilibrio (0x40-0x7F) o un perfil más conservador (0xC0-0xFF). Aunque el usuario final no vea un campo llamado «EPP» en la interfaz, internamente el sistema trabaja con la misma idea de preferencia rendimiento/energía.
EPP, planificadores extendidos y modos de energía automáticos
En el ecosistema Linux más avanzado, el concepto de preferencia energética también influye en tecnologías como sched-ext (Extensible Scheduler Class), que permite implementar planificadores de CPU en BPF y cargarlos dinámicamente. Estos planificadores pueden definir perfiles específicos para juegos, baja latencia, servidores o ahorro energético, ajustando cómo se asignan tareas a CPUs concretas y cómo se minimiza el ruido del sistema operativo.
Un ejemplo es scx_tickless, un planificador orientado a servidores y cargas de computación de alto rendimiento, que concentra los eventos de planificación en un grupo de CPUs primarias para poder desactivar el “tick” del scheduler en las restantes. Dentro de este marco, se definen perfiles con flags pensados para gaming, ahorro de energía, baja latencia o servidor, cada uno con parámetros distintos de frecuencia de comprobación de contención o duración de los time-slices.
Algunos de estos planificadores incorporan un modo de «piloto automático» en el que ajustan su modo de energía (Powersave, Balanced, Performance) en función de la carga de CPU y del perfil energético global del sistema, también conocido como EPP. Es decir, el planificador puede leer la situación energética y adaptar su política de scheduling para complementar la preferencia energética marcada a nivel de hardware.
EPP y eficiencia energética en edificios: una analogía útil
Aunque el término EPP en el contexto de hardware se refiere a Energy Performance Preference, conviene no confundirlo con indicadores de edificación como el Cep,tot, que miden el consumo energético anual de un edificio por superficie (kWh/m²·año) de energía primaria, renovable o no. Sin embargo, la filosofía de fondo es sorprendentemente parecida.
En el ámbito de la construcción, para cumplir con la normativa (por ejemplo, el DB HE 0) es necesario reducir la demanda energética, mejorar el rendimiento de los sistemas y elegir vectores energéticos con mejor factor de conversión. Eso se consigue afinando transmitancias térmicas de la envolvente, reduciendo puentes térmicos, controlando la ventilación, aprovechando ganancias solares, mejorando rendimientos de climatización e iluminación, y usando fuentes de energía más eficientes.
Con un procesador pasa algo muy similar: el «edificio» es la CPU y su plataforma, el «aislamiento» son las tecnologías de bajo consumo y escalado dinámico, y el «vector energético» es el perfil EPP junto con los límites de potencia. Ajustar Energy Performance Preference equivale a definir hasta qué punto estamos dispuestos a gastar vatios por unidad de rendimiento, lo que, en definitiva, es la misma lógica que se aplica al diseñar un edificio energéticamente eficiente.
Al entender a fondo qué es EPP o Energy Performance Preference, cómo se implementa en Linux mediante drivers como amd-pstate y mecanismos CPPC, cómo influye en plataformas Intel como Meteor Lake y Emerald Rapids, y cómo se refleja en sistemas como macOS con XCPM, resulta mucho más sencillo decidir qué perfil se adapta mejor a cada escenario: desde servidores que buscan el mejor rendimiento por vatio hasta portátiles donde la autonomía manda, pasando por sobremesas donde el objetivo es exprimir cada hercio sin disparar el consumo más de la cuenta.
