- El EPP define cuánto prioriza la CPU el rendimiento frente al ahorro energético, usando rangos como 0–255 o 0–100 % según la plataforma.
- Linux expone EPP vía sysfs y drivers como intel_pstate o amd-pstate-epp, mientras que Windows lo gestiona con PerfEnergyPreference y CPPC.
- En procesadores modernos (Intel Meteor Lake, Ryzen móviles, híbridos) el ajuste de EPP impacta en turbo, consumo, temperatura y duración de batería.
- Herramientas como auto-epp en Linux o CPUFriend en macOS permiten afinar finamente la preferencia energía-rendimiento más allá de los perfiles por defecto.
Si has llegado hasta aquí buscando qué es exactamente EPP (Energy Performance Preference) y cómo afecta al rendimiento y consumo de tu CPU en Windows, Linux, macOS o incluso en procesadores Intel y AMD modernos, estás en el sitio correcto. El concepto parece sencillo, pero está lleno de matices, rangos numéricos, modos, drivers y herramientas que pueden marcar una gran diferencia en temperatura, batería y potencia.
A lo largo de este artículo vamos a desgranar de forma clara cómo funciona el parámetro EPP y los distintos modos de energía-rendimiento en cada sistema: desde los ficheros de /sys en Linux y el driver intel_pstate, hasta la configuración oculta de Windows con PerfEnergyPreference, pasando por herramientas de ajuste fino como CPUFriend en macOS o scripts como auto-epp en distribuciones modernas. La idea es que entiendas qué hace cada modo, cómo se configura y qué implicaciones reales tiene en tu día a día.
¿Qué es EPP (Energy Performance Preference)?
El término EPP, Energy Performance Preference, hace referencia a un valor o pista que se le da al procesador para indicarle qué priorizar: el máximo rendimiento, el ahorro de energía o un punto intermedio. En sistemas modernos, este parámetro se implementa principalmente a través de registros como EPP (Energy Performance Preference) o EPB (Energy Performance Bias), o mediante interfaces estandarizadas como CPPC v2 (Collaborative Processor Performance Control).
En la práctica, este ajuste influye en la agresividad con la que la CPU hace “turbo” o escala frecuencias. Un valor más orientado al rendimiento hace que el procesador suba rápido a su máxima frecuencia, mientras que un valor orientado a la eficiencia hace que suba más despacio, permanezca más tiempo en estados de bajo consumo y, en muchos casos, reduzca temperaturas y ruido a costa de algo de potencia.
Rangos numéricos típicos de EPP
En plataformas que exponen el EPP como valor bruto, se suele trabajar con un rango numérico de 0 a 255. Estos números se interpretan así:
- 0: prioridad total al rendimiento, la CPU busca ir lo más rápido posible.
- 255: prioridad máxima a la eficiencia energética, sube menos de vueltas.
- Valores intermedios: equilibrios entre rendimiento y ahorro que el fabricante suele agrupar en modos como
performance,balance_performance,balance_poweropower.
Estos rangos se usan tanto en Linux (por ejemplo con los drivers intel_pstate o amd-pstate-epp), como en macOS en configuraciones avanzadas con CPUFriend, o en la lógica interna de Windows cuando programa registros como el de PerfEnergyPreference a través de CPPC.
EPP en Linux: ficheros sysfs y valores disponibles
En sistemas GNU/Linux modernos, la preferencia de energía-rendimiento se gestiona mediante interfaces en el sistema de ficheros sysfs. Para cada núcleo de CPU existe un fichero clave:
La preferencia actual de energía-rendimiento se puede consultar en /sys/devices/system/cpu/cpu#/cpufreq/energy_performance_preference, donde cpu# es el identificador del núcleo, por ejemplo cpu0. Leyendo este archivo verás valores como performance, balance_performance, balance_power o power, o incluso un número entre 0 y 255 si el sistema permite valores crudos.
Para saber qué modos admite el hardware y el driver, dispones de /sys/devices/system/cpu/cpu#/cpufreq/energy_performance_available_preferences, donde verás listadas las cadenas de texto aceptadas. Esto es muy útil para entender qué combinaciones de rendimiento y eficiencia son soportadas por tu plataforma concreta.
En muchos sistemas se permite además escribir directamente un valor numérico de 0 a 255 en energy_performance_preference. Cuanto más cerca de 0, más rendimiento; cuanto más cerca de 255, más eficiencia. Este control granular es ideal para quienes quieren afinar al máximo, aunque en la práctica la mayoría de usuarios se quedan con los modos predefinidos legibles por nombre.
Ejemplo práctico en Linux con AMD-Pstate-EPP y auto-epp
En hardware AMD moderno, especialmente en portátiles con procesadores Ryzen como un AMD Ryzen 7 7840U, muchas distribuciones como openSUSE Tumbleweed activan por defecto el driver amd-pstate-epp. Este driver aparece, por ejemplo, al leer /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver, donde verás la cadena amd-pstate-epp cuando está en uso.
Normalmente, el estado de este driver se consulta en /sys/devices/system/cpu/amd_pstate/status, donde el valor active indica que está desplegado como mecanismo de escalado principal. Además, el gobernador por defecto en muchos portátiles modernos suele ser powersave, que visto desde el driver AMD no significa “ir lento”, sino aplicar una lógica similar a schedutil u ondemand pero optimizada para el hardware concreto.
Para la capa de usuario, escritorios como KDE Plasma o GNOME se apoyan en power-profiles-daemon, un servicio de fondo que expone perfiles como Performance, Balanced o Power Saver. En un sistema con power-profiles-daemon.service activo, es frecuente configurar simplemente “Rendimiento en CA” y “Equilibrado en batería”, dejando que el demonio ajuste internamente frecuencias, EPP y gobernadores.
Sobre esa base, muchos usuarios añaden herramientas adicionales como auto-epp, un script que automatiza el cambio de EPP usando el driver AMD-Pstate. Esta utilidad lee una configuración en /etc/auto-epp.conf con variables como epp_state_for_AC y epp_state_for_BAT, y aplica estados como performance, balance_performance, balance_power o power según si el equipo está enchufado o en batería.
Imagina un portátil configurado inicialmente con epp_state_for_AC=balance_performance y epp_state_for_BAT=power. En este caso, el modo de batería ultraconservador puede limitar la frecuencia de un Ryzen 7840U a alrededor de 1,4 GHz incluso en carga, cuando el turbo máximo de un solo núcleo ronda los 5,1 GHz. El resultado es una sensación de equipo “capado” que no exprime el procesador.
Cambiando la configuración a epp_state_for_AC=performance y epp_state_for_BAT=balance_performance, se consigue que en CA la CPU se acerque a su máximo potencial, mientras que en batería mantiene aproximadamente un 90-95 % del rendimiento máximo cuando hace falta, pero sin disparar el consumo de forma tan extrema.
Adicionalmente, configuraciones como balance_power para batería ofrecen un equilibrio todavía más eficiente, con un rendimiento cercano al 85-90 % pero con un ahorro de energía notable. Usuarios que han probado estas combinaciones reportan mejoras de hasta una hora extra de autonomía en modo balance_performance, y temperaturas medias reducidas en torno a 3-5 ºC, llegando incluso a descensos de unos 8 ºC al pasar a balance_power en tareas ligeras como navegación web y edición de texto.
Modos EPP en Intel Meteor Lake: impacto en rendimiento y consumo
La familia Intel Meteor Lake, con modelos como el Core Ultra 7 155H, explota muy bien el concepto de EPP. En portátiles recientes, estos procesadores permiten cambiar entre modos de EPP equilibrado, rendimiento y ahorro de energía, lo que afecta tanto a la CPU como a la gráfica integrada (tGPU) y al consumo global del equipo.
En pruebas sintéticas de GPU como 3DMark Wild Life Extreme, el modo EPP equilibrado ha mostrado valores en torno a 91,35 FPS con un pico de 69 W, mientras que el modo rendimiento se queda aproximadamente en 87,67 FPS pero con picos de hasta 82 W. El modo ahorro de energía ronda los 80,93 FPS con un máximo de 63 W. Curiosamente, el modo “rendimiento” no siempre aporta más FPS frente al equilibrado, pero sí dispara más el consumo.
En benchmarks de navegador como JetStream 2 con Firefox y Selenium, el modo rendimiento obtiene alrededor de un 10 % más de puntuación que el equilibrado, a costa de subir el consumo de CPU de unos 58 W a cerca de 63 W. En modo ahorro, el rendimiento cae a aproximadamente la mitad, pero la CPU puede moverse apenas en 20 W, lo que dispara la eficiencia medida como rendimiento por vatio, llegando a cifras del orden de 15.464 puntos frente a 8.555 (equilibrado) y 7.652 (rendimiento).
En aplicaciones como GIMP, el modo de bajo consumo hace que las tareas tarden casi el doble, pero con consumos que bajan a unos 18 W frente a 44 W o 53 W de los otros modos, lo que es muy significativo en portátiles finos. En Blender 4.0, sin embargo, apenas hay diferencia apreciable en rendimiento entre modos, aunque el modo ahorro reduce el consumo en torno a 10 W y limita la frecuencia a unos 2,8 GHz máximos.
Si se agregan todos los benchmarks, se observa que el modo rendimiento supera al equilibrado por un margen modesto, con algo como 445,6 puntos frente a 429, mientras que el modo de ahorro se queda bastante rezagado en torno a 316,35 puntos. Esto implica una mejora de apenas un 4 % en puntuación total a cambio de un incremento de consumo cercano al 22 % en modo rendimiento, lo que no siempre merece la pena salvo en escenarios muy concretos.
A nivel de frecuencias, el modo de ahorro limita la media a unos 2414 MHz, mientras que el modo equilibrado suele rondar los 3193 MHz y el modo rendimiento sube a aproximadamente 3651 MHz. De forma paralela, las temperaturas medias bajan en torno a 8 grados en el modo de ahorro, con un consumo medio que se aproxima a la mitad del modo de rendimiento, lo que deja claro cómo el EPP puede inclinar de forma drástica el equilibrio entre silencio, duración de batería y potencia bruta.
EPP y perfEnergyPreference en Windows
En Windows, el control equivalente al EPP se expone mediante la configuración oculta PerfEnergyPreference, que define el valor que se programa en el registro de preferencia energía-rendimiento en sistemas que implementan la versión 2 de la interfaz CPPC y trabajan en modo autónomo.
El parámetro PerfEnergyPreference se expresa como porcentaje entre 0 y 100. Un valor de 0 hace que Windows programe el registro interno a 0, priorizando por completo el rendimiento. Un valor de 100 se traduce internamente a 255, inclinando totalmente la balanza hacia el ahorro de energía. Para valores intermedios, el sistema aplica la fórmula (valor * 255) / 100, de manera que se mapea el rango 0-100 % al rango 0-255 que entiende el hardware.
Este ajuste está disponible como parte de las políticas de energía, aunque suele marcarse como opción oculta. A nivel de alias:
- En aprovisionamiento de Windows:
Common\Power\Policy\Settings\Processor\PerfEnergyPreferenceyPerfEnergyPreference1. - En
powercfg: se exponen comoPERFEPPyPERFEPP1.
Los valores aceptados van desde 0 a 100, y se aplican en distintas ediciones del sistema: Windows 10 de escritorio (Home, Pro, Enterprise, Education) soporta este ajuste en arquitecturas x86 y x64, Windows 10 Mobile sólo en ARM, y Windows 11 de escritorio en x64 y ARM. En muchos equipos portátiles modernos, el fabricante preconfigura estos valores en los planes de energía propios, y toquetearlos puede cambiar notablemente la forma en que la CPU sube y baja de vueltas, e incluso ayudar a hacer que Windows 11 consuma menos batería.
Ajuste de EPP y turbo en macOS con CPUFriend
En macOS, Apple usa su propio sistema de gestión de energía basado en XCPM (XNU CPU Power Management) y en el plugin X86PlatformPlugin. Para que funcione correctamente en hardware compatible (como Haswell o posterior), es importante que el kernel cargue ese plugin y que se haya configurado bien una tabla ACPI de tipo SSDT-PLUG apuntando al primer hilo lógico del procesador (CP00 o similar).
En equipos en los que la gestión nativa no es suficiente o se quiere afinar todavía más, se puede recurrir a herramientas como CPUFriend y el script auxiliar CPUFriendFriend. Estas utilidades permiten generar un CPUFriendDataProvider.kext o un ssdt_data.aml que inyectan datos de energía personalizados, incluyendo valores clave como el LFM (Low Frequency Mode), el propio EPP y un llamado Performance Bias.
El LFM se interpreta como el “suelo” de frecuencia al que puede bajar la CPU en reposo. Para determinarlo, se puede consultar el campo TDP-down Frequency en Intel ARK, o usar valores recomendados, como:
| Generación | LFM | Equivalencia aproximada |
|---|---|---|
| Portátiles Broadwell y posteriores | 08 | ~800 MHz |
| Sobremesa Broadwell y posteriores | 0A | ~1000 MHz |
| Haswell/Broadwell HEDT/servidor (X99) | 0D | ~1300 MHz |
| Skylake+ HEDT/servidor (X299) | 0C | ~1200 MHz |
Estos valores se codifican como multiplicadores en hexadecimal, por ejemplo, 13 para 1,3 GHz, y afectan a cómo macOS maneja las transiciones de sueño y despertar.
El parámetro EPP en macOS se configura también como un valor entre 00 y FF, donde 00 indica que el sistema debe permitir que la CPU turbee lo más rápido posible, y FF que debe hacerlo de manera muy suave. Por convención se suele agrupar así:
| Rango EPP | Comportamiento |
|---|---|
| 0x00-0x3F | Máximo rendimiento |
| 0x40-0x7F | Rendimiento equilibrado |
| 0x80-0xBF | Equilibrio tirando a ahorro |
| 0xC0-0xFF | Ahorro máximo |
Es importante tener en cuenta que solo SMBIOS Skylake y posteriores soportan oficialmente este campo de EPP, y que un mal ajuste puede romper la estabilidad, provocar kernel panics con mensajes como Sleep Wake failure in efi o empeorar el consumo en lugar de mejorarlo.
En arquitecturas más antiguas como Sandy Bridge e Ivy Bridge, macOS no usa XCPM de forma nativa en versiones recientes, por lo que se recurre a scripts como ssdtPRGen para generar tablas de gestión de energía (SSDT-PM) específicas. Este enfoque se combina con ajustes en ACPI (por ejemplo, manipular entradas _PSS o _PPC) y puede influir indirectamente en cómo el sistema reparte frecuencias y estados de energía, aunque no exponga un EPP tan directo como en Skylake+.
El driver intel_pstate en Linux y sus modos
El driver intel_pstate forma parte del subsistema de escalado de rendimiento de CPU (CPUFreq) en el kernel Linux, y está diseñado para procesadores Intel desde Sandy Bridge en adelante (aunque no todos los modelos están soportados). A diferencia de drivers genéricos como acpi-cpufreq, trabaja directamente con el interfaz de P-states del hardware y mapea esos estados a frecuencias entendibles por el resto del sistema.
Para cada CPU lógica, intel_pstate crea una política independiente, ya que la interfaz hardware se expone a nivel de núcleo. No es un módulo descargable: se configura mediante parámetros de línea de arranque del kernel (como intel_pstate=active o intel_pstate=passive), y se controla en caliente a través de sysfs en /sys/devices/system/cpu/intel_pstate/.
Este driver puede operar en dos modos:
- Modo activo: usa sus propios algoritmos de selección de P-state, o deja que el hardware (HWP) se gestione solo recibiendo pistas.
- Modo pasivo: se comporta como un driver
CPUFreqestándar, atendiendo a los valores que le pidan gobernadores genéricos comoschedutiloondemand.
En modo activo con HWP, el driver confía en que el procesador seleccione automáticamente los P-states, pero le envía “hints” a través de registros como el EPP o el EPB. En ese modo, los algoritmos disponibles se llaman también powersave y performance, aunque no se comportan igual que los gobernadores genéricos homónimos, lo que suele generar confusión.
Cuando HWP está activado y eliges el algoritmo performance, intel_pstate escribe un valor 0 en el EPP/EPB, indicando que el foco debe estar en el máximo rendimiento. Esto ignora cualquier configuración previa de EPP que se hubiera hecho desde sysfs y rechaza nuevos intentos de cambiarlo a un valor distinto de 0.
Si usas el algoritmo powersave con HWP, el driver respeta el valor de EPP/EPB configurado en sysfs o el que haya dejado la UEFI/BIOS, lo que normalmente hace que el hardware se comporte de manera menos agresiva y favorezca el equilibrio o la eficiencia en lugar del pico de potencia.
En modo activo sin HWP, intel_pstate implementa su propio cálculo de P-states basándose en contadores internos del procesador. El algoritmo performance selecciona siempre el P-state máximo permitido, mientras que powersave ajusta el P-state de forma proporcional a la utilización de CPU, con una cadencia mínima de unos 10 ms entre ajustes.
En modo pasivo, el driver se presenta al sistema como intel_cpufreq y expone el rango completo de P-states (incluyendo turbo) a los gobernadores genéricos. De este modo, la política de escalado se decide externamente, mientras que intel_pstate se limita a traducir las peticiones en cambios reales de frecuencia.
Turbo, límites de P-state y EPP en intel_pstate
En procesadores Intel, el rango de P-states se divide normalmente en dos subconjuntos: los P-states sostenibles (por debajo del umbral de turbo) y los turbo P-states, que solo son mantenibles durante intervalos limitados por el presupuesto térmico y de potencia.
El driver intel_pstate siempre expone todo el rango de P-states al sistema, incluyendo el tramo turbo, lo que hace que se usen estados turbo con mayor frecuencia que con acpi-cpufreq, el cual suele representar todo el rango turbo con una sola entrada en las tablas _PSS. Esta diferencia es clave a la hora de que gobernadores como schedutil puedan aprovechar más el techo de rendimiento.
Para limitar el uso de turbo de forma global, existe el atributo no_turbo en /sys/devices/system/cpu/intel_pstate/. Cuando se pone a 1, intel_pstate deja de usar cualquier P-state por encima del umbral de turbo, aunque la frecuencia máxima reportada (cpuinfo_max_freq) siga reflejando el valor turbo máximo. Esta discrepancia se resuelve internamente limitando los valores máximos de scaling_max_freq y scaling_min_freq al techo no turbo.
Además de no_turbo, el driver dispone de varios atributos globales importantes:
max_perf_pct: porcentaje máximo del nivel de rendimiento (turbo incluido) que se puede solicitar.min_perf_pct: porcentaje mínimo de rendimiento permitido.num_pstatesyturbo_pct: número total de P-states y proporción que ocupa el tramo turbo, cuando son constantes entre CPUs.status: indica si el driver está en modoactive,passiveuoff, y permite cambiar entre modos.hwp_dynamic_boost: cuando se usa HWP, permite subir temporalmente el límite mínimo de P-state al despertar de I/O para mejorar la reactividad.
Por otro lado, cuando HWP está disponible, intel_pstate habilita un interfaz semejante al EPP descrito antes: energy_performance_preference y energy_performance_available_preferences para cada CPU en /sys/devices/system/cpu/cpu#/cpufreq/. Desde ahí, el usuario puede elegir valores semánticos como performance, balance_performance, balance_power, power o default, o incluso escribir un entero entre 0 y 255 si EPP está soportado directamente.
Detrás de estas cadenas, el driver traduce internamente a un valor numérico que se escribe en el registro de Energy-Performance Preference (EPP) o en el Energy-Performance Bias (EPB), de manera muy similar a lo explicado para Windows con el parámetro PerfEnergyPreference.
intel_pstate frente a acpi-cpufreq y modelos híbridos
En muchos sistemas, la BIOS/UEFI proporciona tablas ACPI con objetos _PSS que enumeran P-states soportados. El driver acpi-cpufreq usa esos datos para escalar frecuencia, pero queda limitado a los estados que aparecen listados, y representa el tramo turbo con una sola entrada cuya frecuencia es, por convención, 1 MHz mayor que la del P-state no turbo más alto.
Este enfoque hace que los gobernadores genéricos tiendan a quedarse más tiempo en estados no turbo, porque el tramo turbo ocupa “solo” 1 MHz de todo el rango y parece marginal en términos de porcentaje. Además, en sistemas con Configurable TDP, una mala coordinación entre el umbral de turbo real y las entradas _PSS puede provocar que haya varias entradas turbo y que desactivar turbo no sea tan directo como ignorar la última entrada.
Por el contrario, intel_pstate conoce el umbral exacto de turbo y expone el rango entero, lo que facilita una gestión coherente del atributo no_turbo y un uso más agresivo y eficiente de los estados turbo cuando se desean.
En procesadores híbridos (núcleos grandes y pequeños), intel_pstate habilita además Capacity-Aware Scheduling (CAS) y, si el kernel está configurado con CONFIG_ENERGY_MODEL, activa Energy-Aware Scheduling (EAS). En ese contexto, define capacidades por CPU basadas en los niveles HWP máximos y construye un modelo de energía “artificial” para ayudar al planificador a colocar tareas donde resulten más eficientes, favoreciendo cores pequeños o poco cargados siempre que tengan capacidad suficiente.
Esta combinación de CAS + EAS, junto con el uso de EPP/HWP, permite que en procesadores modernos el sistema sea capaz de situar tareas ligeras en núcleos eficientes con un coste energético muy bajo, reservando los núcleos grandes para cargas intensivas, todo ello ajustado por las preferencias de energía-rendimiento establecidas.
Juntando todo lo anterior, el EPP se convierte en una especie de “mando de mezcla” entre potencia y eficiencia que atraviesa sistemas operativos, drivers y arquitecturas: en Linux se controla a través de sysfs y drivers como intel_pstate o amd-pstate-epp, en Windows mediante parámetros como PerfEnergyPreference integrados en CPPC, y en macOS con herramientas de bajo nivel como CPUFriend y XCPM. Entender cómo se expresa (0-255, 0-100 %), qué modos semánticos ofrece (performance, balance_performance, balance_power, power) y cómo interactúa con tecnologías como HWP, turbo o el agendador híbrido es la clave para ajustar de verdad tu equipo, ya sea para exprimir hasta el último FPS o para rascar esa hora extra de batería que tanto se agradece.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.