Mi objetivo es configurar un mini servidor (no HTPC) con bajo consumo de energía en modo inactivo, pero que ofrece un buen rendimiento cuando se usa. La atención se centra más en la seguridad de los datos que en la disponibilidad. En otras palabras: piezas de calidad, pero redundancia solo para almacenamiento.

Sin considerarme parcial, después de algunas investigaciones, sentí que algunas APU de escritorio AMD ofrecerían un buen valor.

Las preguntas restantes son:

• ¿El estado inactivo de la GPU reducirá el consumo de energía y desatará recursos para la CPU?
• ¿Cool'n'Quiet y Turbo Core conducirán al bajo consumo de energía previsto en modo inactivo pero al rendimiento bajo carga?
• ¿Linux admitirá este escenario según lo previsto? Unas cuantas preguntas y discusiones en el foro parecen sugerir que este no es necesariamente el caso.

[Editar: Conclusiones sobre la elección del procesador]

• AMD vs AMD:
  • Richland hace un trabajo mucho mejor que Trinity aquí.
  • Kaveri no puede competir con la disipación de energía en modo inactivo de Richland (al menos por ahora).
  • La GPU del A10-6700 puede estar sobrevalorada, pero es un poco triste que no se use mucho. Algunos algoritmos pueden desplegar su poder computacional. Sin embargo, no tengo idea de cómo eso afectará el consumo de energía del procesador.
  • Sospecho que el A10-6790K es el mismo procesador que el A10-6700 con solo un conjunto de parámetros diferente para los aumentos de Turbo Core. Si esto es cierto, el A10-6790K podrá aumentar por más tiempo y / o proporcionar frecuencias más altas a largo plazo debido a su mayor TDP. Pero necesitará un ventilador de CPU diferente para eso (piense en el espacio y la temperatura / vida útil).
• AMD A10-6700 vs Intel Core i3-3220:
  • El A10-6700 tiene mucha más potencia de GPU, que no se usa aquí.
  • El i3-3220 tiene una menor disipación de energía en modo inactivo.
  • Si bien en los puntos de referencia típicos el i3-3220 es más rápido para los cálculos, no puedo ver cómo sus dos núcleos de hiperprocesamiento podrían manejar solicitudes paralelas (por ejemplo, a una base de datos con interfaces web) tan rápido como cuatro núcleos con todas las funciones (al menos cuando se supone un almacenamiento en caché serio). Sin embargo, no encontré ningún punto de referencia serio, solo algunas indicaciones.

[Editar: el bapmparámetro del controlador radeon gratuito está configurado de forma predeterminada para Kaveri, Kabini y sistemas de escritorio Trinity, Richland a partir de Linux 3.16]

Ver [pull] radeon drm-fixes-3.16 .

Sin embargo, con respecto a Debian basado en 3.16, los valores predeterminados no parecen funcionar (¿todavía?), Mientras que el parámetro de arranque sí. Consulte Cómo configurar un sistema Debian (enfoque en 2D o consola / servidor) con una APU AMD Turbo Core para obtener la máxima eficiencia energética y de computación.

[Editar: el controlador radeon gratuito pronto tendrá un bapmparámetro]

Dado que la conclusión de lo siguiente es usar una versión parcheada del radeoncontrolador gratuito con su APU para admitir Turbo Core y aprovecharla al máximo (excepto los gráficos 3D), si puede (habilitar bapmpuede generar inestabilidades en algunas configuraciones) ), es una gran noticia que las futuras versiones de radeon tendrán un parámetro para habilitar bapm .

[Sigue la publicación original]

Experiencia APU AMD A10-6700 (Richland)

Elección del procesador

Mi primera PC fue una 486DX2-66 configurada a partir de docenas de disquetes de 3.5 "que contienen paquetes fuente de Slackware. Desde entonces, muchas cosas han cambiado, y muchas industrias parecen estar actualmente en la fase en la que todavía aumentan el número de variantes de producto.

Esta circunstancia y algunas de las desafortunadas decisiones de AMD en el pasado reciente no me han hecho más fácil decidir sobre una plataforma para un mini servidor. Pero finalmente, decidí que el A10-6700 sería una buena opción:

• Varias revisiones han demostrado que un Kaveri (todavía no disponible) consumirá más energía en modo inactivo que un Richland o un Trinity
• La ventaja del Richland A10-6700 sobre el Trinity A10-5700 parece ser significativa: frecuencia más baja y más alta, Turbo Core más fino (considerando también la temperatura, una gran ventaja cuando la GPU estará inactiva)
• Se dice que la GPU del A10-6700 está sobrevalorada (nomenclatura impulsada por el marketing) y el precio de la APU parece justo

Otros componentes y configuración

A pesar de los innumerables procesadores para elegir, no hay muchas placas Mini-ITX disponibles. El ASRock FM2A78M-ITX + parecía ser una opción razonable. La prueba se realizó con el firmware V1.30 (no hay actualizaciones disponibles mientras escribo esto).

Solo se debe consumir el 80% de la salida nominal de una fuente de alimentación. Por otro lado, muchos no funcionan de manera eficiente por debajo del 50% de carga. Es muy difícil encontrar una fuente de energía eficiente para un sistema con un rango de disipación de energía estimado de 35W a 120W. Realicé estas pruebas con un Seasonic G360 80+ Gold porque supera a la mayoría de los competidores con respecto a la eficiencia a bajas cargas.

Dos RAM DDR3-1866 de 8 GB (configuradas como tales, lo que hace la diferencia en comparación con 1333), una unidad SSD y un ventilador de CPU de calidad controlada por PWM también fueron parte de la configuración de prueba.

Las mediciones se realizaron utilizando un AVM Fritz! DECT 200 que se ha informado que realiza mediciones precisas. Aún así, la plausibilidad se validó utilizando un dispositivo antiguo sin nombre. No se pudieron identificar inconsistencias. La disipación de energía medida del sistema incluirá la eficiencia reducida de la fuente de alimentación para cargas más bajas.

Se conectó una pantalla [W] QHD a través de HDMI.

La memoria compartida inicial para la GPU se estableció en 32M en el BIOS UEFI. Además, la GPU integrada se seleccionó como Primaria y se habilitó IOMMU.

No se instaló ni configuró ninguna X u otro sistema gráfico. La salida de video se restringió al modo de consola.

Lo esencial

Hay algunas cosas que uno necesita saber.

• Si bien la decisión sobre Cool'n'Quiet la toma un software fuera de los procesadores, Turbo Core es una decisión tomada de forma autónoma por un microcontrolador adicional en la APU (o CPU).
• Muchas herramientas, así como /procy /syslugares no informan de la actividad de Turbo Core. cpufreq-aperf, cpupower frequency-infoy cpupower monitorhacer, pero solo después modprobe msr.

Grupo de casos de prueba 1: Linux + radeon

Empecé con Arch Linux nuevo (instalador 2014.08.01, kernel 3.15.7). El factor clave aquí es la presencia de acpi_cpufreq(escala de CPU del núcleo) y radeon(controlador de GPU del núcleo) y la forma fácil de parchear radeon.

Caso de prueba 1.1: BIOS TC on - CnQ on / Linux OnDemand - Boost

Configuración UEFI BIOS Turbo Core ............................ habilitado
Configuración UEFI BIOS Cool'n'Quiet .......................... habilitado
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frecuencia-información" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Rango de cpu MHz "/ proc / cpuinfo" observado ... 1800 - 3700
Rango de frecuencia de "monitor cpupower" observado ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nivel de potencia 0

Carga | Frecuencias principales
--------------- + -----------
estrés - CPU 1 | 1 x 3700
estrés - CPU 2 | 2 x 3700
estrés - CPU 3 | 3 x 3700
estrés - CPU 4 | 4 x 3700

Caso de prueba 1.2: BIOS TC on - CnQ on / Linux Performance - Boost

Configuración UEFI BIOS Turbo Core ............................ habilitado
Configuración UEFI BIOS Cool'n'Quiet .......................... habilitado
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... rendimiento 

"cpupower frecuencia-información" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Rango de cpu MHz "/ proc / cpuinfo" observado ... 3700
Rango de frecuencia de "monitor de cpupower" observado ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nivel de potencia 0

Carga | Frecuencias principales
--------------- + -----------
estrés - CPU 1 | 1 x 3700
estrés - CPU 2 | 2 x 3700
estrés - CPU 3 | 3 x 3700
estrés - CPU 4 | 4 x 3700

Resumen del grupo de casos de prueba 1

Los aumentos basados ​​en Turbo Core son imposibles en este escenario porque el radeoncontrolador actualmente desactiva la bapmbandera debido a problemas de estabilidad en algunos escenarios . Por lo tanto, se omitieron más pruebas.

Grupo de casos de prueba 2: Linux + radeon parcheado con bapm

A fin de que bapm, empecé con un Arch Linux fresca (instalador 01/08/2014, kernel 3.15.7), me dieron el core linuxpaquete a través de ABS(3.15.8), editado el PKGBUILDuso pkgbase=linux-tc, sacó las fuentes con makepkg --nobuild, modificado pi->enable_bapm = true;en trinity_dpm_init()en src/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.c, y compilado con makepkg --noextract. Luego, lo instalé ( pacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xzy pacman -U linux-tc-3.15.8-1-x86_64.pkg.tar.xz) y actualicé GRUB( grub-mkconfig -o /boot/grub/grub.cfgpero, por supuesto, YMMV).

Como resultado, me dieron la opción de arrancar linuxo linux-tc, y las siguientes pruebas se refieren a este último.

Caso de prueba 2.1: BIOS TC on - CnQ on / Linux OnDemand - Boost

Configuración UEFI BIOS Turbo Core ............................ habilitado
Configuración UEFI BIOS Cool'n'Quiet .......................... habilitado
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frecuencia-información" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Rango de cpu MHz "/ proc / cpuinfo" observado ... 1800 - 3700
Rango de frecuencia de "monitor cpupower" observado ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nivel de potencia 0

Carga | Frecuencias principales
--------------- + -----------------
estrés - CPU 1 | 1 x 4300
estrés - CPU 2 | 2 x 4200 .. 4100
estrés - CPU 3 | 3 x 4100 .. 3900
estrés - CPU 4 | 4 x 4000 .. 3800

Caso de prueba 2.2: BIOS TC on - CnQ on / Linux Performance - Boost

Configuración UEFI BIOS Turbo Core ............................ habilitado
Configuración UEFI BIOS Cool'n'Quiet .......................... habilitado
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... performace

"cpupower frecuencia-información" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Rango de cpu MHz "/ proc / cpuinfo" observado ... 3700
Rango de frecuencia de "monitor de cpupower" observado ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nivel de potencia 0

Carga | Frecuencias principales
--------------- + -----------------
estrés - CPU 1 | 1 x 4300
estrés - CPU 2 | 2 x 4200 .. 4100
estrés - CPU 3 | 3 x 4100 .. 3900
estrés - CPU 4 | 4 x 4000 .. 3800

Caso de prueba 2.3: BIOS TC on - CnQ on / Linux OnDemand - No Boost

Configuración UEFI BIOS Turbo Core ............................ habilitado
Configuración UEFI BIOS Cool'n'Quiet .......................... habilitado
/ sys / devices / system / cpu / cpufreq / boost ................... 0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand

"cpupower frecuencia-información" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Rango de cpu MHz "/ proc / cpuinfo" observado ... 1800 - 3700
Rango de frecuencia de "monitor cpupower" observado ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nivel de potencia 1

Carga | Frecuencias principales
--------------- + -----------
estrés - CPU 1 | 1 x 3700
estrés - CPU 2 | 2 x 3700
estrés - CPU 3 | 3 x 3700
estrés - CPU 4 | 4 x 3700

Caso de prueba 2.4: BIOS TC on - CnQ on / Linux Performance - No Boost

Configuración UEFI BIOS Turbo Core ............................ habilitado
Configuración UEFI BIOS Cool'n'Quiet .......................... habilitado
/ sys / devices / system / cpu / cpufreq / boost ................... 0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... performace

"cpupower frecuencia-información" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Rango de cpu MHz "/ proc / cpuinfo" observado ... 3700
Rango de frecuencia de "monitor de cpupower" observado ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nivel de potencia 1

Carga | Frecuencias principales
--------------- + -----------
estrés - CPU 1 | 1 x 3700
estrés - CPU 2 | 2 x 3700
estrés - CPU 3 | 3 x 3700
estrés - CPU 4 | 4 x 3700

Caso de prueba 2.5: BIOS TC apagado - CnQ on / Linux OnDemand - Boost

Configuración UEFI BIOS Turbo Core ............................ deshabilitado
Configuración UEFI BIOS Cool'n'Quiet .......................... habilitado
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frecuencia-información" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Rango de cpu MHz "/ proc / cpuinfo" observado ... 1800 - 3700
Rango de frecuencia de "monitor cpupower" observado ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nivel de potencia 0

En otras palabras, si Turbo Core está deshabilitado en el BIOS, el parche radeonno lo activará.

Caso de prueba 2.6: BIOS TC activado - CnQ desactivado / Linux n / a

Configuración UEFI BIOS Turbo Core ............................ habilitado
Configuración UEFI BIOS Cool'n'Quiet .......................... Deshabilitado
/ sys / devices / system / cpu / cpufreq / boost ................... n / a
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... n / a

"cpupower frecuencia-información" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Rango de cpu MHz "/ proc / cpuinfo" observado ... 3700
Rango de frecuencia de "monitor de cpupower" observado ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nivel de potencia 0

Carga | Frecuencias principales
--------------- + -----------------
estrés - CPU 1 | 1 x 4300
estrés - CPU 2 | 2 x 4100 .. 4000
estrés - CPU 3 | 3 x 4000 .. 3800
estrés - CPU 4 | 4 x 3900 .. 3700

Con Cool'n'Qiet deshabilitado, el kernel de Linux no ofrecerá ninguna opción de gobernador y (erróneamente) asumirá que los núcleos se ejecutan a una frecuencia fija. Curiosamente, las frecuencias de Turbo Core resultantes son la peor de todas las combinaciones probadas en el Grupo de casos de prueba 2.

Resumen del grupo de casos de prueba 2

Con el radeoncontrolador parcheado , Turbo Core funciona. bapmHasta el momento no se ha visto ninguna inestabilidad (que es la razón por la que también se desactiva Turbo Core).

Grupo de casos de prueba 3: Linux + fglrx (catalizador)

Comencé con una nueva instalación de Ubuntu (14.04 Server, kernel 3.13), que veo como comparable a Arch Linux (instalador 2014.08.01, kernel 3.15.7) debido a la presencia de acpi_cpufreq(escala de CPU del núcleo) y radeon(controlador de GPU del núcleo ) La razón para cambiar a Ubuntu es la fácil instalación de fglrx. Validé el consumo de energía y el comportamiento con la instalación nueva, que utiliza radeon.

Instalé fglrxdesde la línea de comandos ( sudo apt-get install linux-headers-generic, sudo apt-get install fglrx) y reinicié el sistema. El cambio de radeona fglrxes inmediatamente obvio tanto con respecto a la apariencia de la consola ( fglrx: 128 x 48 radeon,: mucho mayor) como al consumo de energía en modo inactivo ( fglrx: 40W,: radeon30W). Pero Turbo Core funciona de inmediato.

Caso de prueba 3.1: BIOS TC on - CnQ on / Linux OnDemand - Boost

Configuración UEFI BIOS Turbo Core ............................ habilitado
Configuración UEFI BIOS Cool'n'Quiet .......................... habilitado
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frecuencia-información" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Rango de cpu MHz "/ proc / cpuinfo" observado ... 1800 - 3700
Rango de frecuencia de "monitor cpupower" observado ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... n / a

Carga | Frecuencias principales
--------------- + ----------------------------
estrés - CPU 1 | 1 x 4300
estrés - CPU 2 | 2 x 4200 .. 3900 (core chg)
estrés - CPU 3 | 3 x 4100 .. 3700
estrés - CPU 4 | 4 x 4000 .. 3600

El fglrxcomportamiento es definitivamente interesante. Cuando se solicitó 'stress --cpu 2' para cualquiera de los casos de prueba en cualquier grupo de casos de prueba, los dos núcleos cargados siempre se ubicaron en módulos separados. Pero fglrx, con una reasignación repentina, se utilizó un solo módulo (lo que ahorra bastante energía, ver más abajo). Después de un tiempo, el núcleo cargado regresó al otro módulo. Esto no fue visto con radeon. ¿Podría ser que fglrxmanipula la afinidad central de los procesos?

Resumen del grupo de casos de prueba 3

La ventaja de esto fglrxes que permite Turbo Core de inmediato, sin necesidad de parchearlo.

Debido a que fglrxdesperdicia de 10 a 12 W para la GPU en nuestro escenario en un chip con TDP de 65 W, los resultados generales con respecto a las velocidades centrales disponibles no son impresionantes. Por lo tanto, no se realizaron más pruebas.

También desde un punto de vista de ingeniería, el comportamiento de fglrxparece ser un poco triste. La reasignación de uno de los dos núcleos ocupados al otro módulo para mantener una frecuencia más alta puede o no ser una buena idea, porque antes de ese paso, ambos núcleos tenían un caché L2 propio, mientras que luego tenían que compartir uno. Si se fglrxconsidera alguna métrica (como errores de aciertos de caché) para respaldar su decisión, deberá aclararse por separado, pero hay otros informes sobre su comportamiento brusco .

Resumen del consumo de energía

Algunos de los valores delta en la siguiente tabla empeoran ligeramente a medida que aumenta la temperatura; se podría decir que el ventilador controlado por PWM y el chip juegan un papel allí.

System @State / -> Transition Delta | Disipación de energía del sistema
------------------------------------- + ------------ -------------
  @BIOS | @ 95 .. 86W
  @Bootloader | @ 108 .. 89W
  @Ubuntu Installer Idle | @ 40W
  @Linux radeon Idle ondemand | @ 30W
  @Linux radeon Rendimiento inactivo | @ 30W
  @Linux fglrx Idle ondemand | @ 40W
  1 Módulo 1800 -> 3700 | + 13W
  1 Módulo 1800 -> 4300 | + 25W
  1 núcleo 1800 -> 3700 | + 5W
  1 núcleo 1800 -> 4300 | + 10W
  Salida de video "radeon" -> Desactivar | - 2W
  Salida de video 'fglrx "-> Oscurecer | + - 0W
  @Linux radeon Maximum | @ 103 .. 89W
  @Linux fglrx Máximo | @ 105 .. 92W

• Parece haber más de Turbo Core (al menos con las APU Richland) de lo esperado: no hay una diferencia notable en la disipación de potencia cuando el gobernador de escala "bajo demanda" está en su lugar en comparación con cuando el gobernador de "rendimiento" está en su lugar. Althouth /proc/cpuinfosiempre reportará 37000MHz bajo el gobernador de rendimiento, cpupower monitorrevelará que los núcleos realmente se ralentizan. En algunos casos, se mostraron frecuencias tan bajas como 2000MHz; Es posible que 1800MHz se utilicen internamente también.
• El A10-6700 consta de dos módulos con dos núcleos cada uno. Si, por ejemplo, dos núcleos están inactivos y dos núcleos están ocupados y se aceleran, el comportamiento del sistema será diferente dependiendo de si los núcleos ocupados están ubicados en el mismo módulo o no.
  • Acelerar un módulo requiere más energía que acelerar un núcleo.
  • El caché L2 se asigna por módulo.
• La diferencia entre la disipación de potencia de dos núcleos que aceleran en el mismo módulo frente a módulos diferentes se determinó mediante el reemplazo stress --cpu 2(que siempre condujo a una distribución entre los dos módulos) por .taskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1
• El A10-6700 parece tener un límite de disipación de energía total para la APU (92W junto con los otros componentes) con un bit pequeño reservado solo para la GPU (3 W). Con radeon, permitirá más por un período corto y se reducirá al máximo de manera muy suave, mientras que con fglrx, se ha observado que estos límites se superan de manera más significativa y la disipación de potencia se reduce abruptamente.
• Si bien muchas personas afirman que el retraso en la disponibilidad de Kaveri está previsto por AMD porque mataría sus APU actuales, les ruego que difieran. El Richland A10 ha demostrado una excelente administración de energía, y el Kaveri no puede competir con su bajo consumo de energía en estado inactivo (la complejidad del chip de Kaveri es casi el doble que la de Richland, por lo que tomará uno o dos pasos de desarrollo más).

Conclusión general

• La inclusión de la temperatura en la lógica Turbo Core (como se informa para el paso Trinity -> Richland) parece tener sentido y parece funcionar bien, como puede verse por la reducción en la disipación de potencia en BIOS y Bootloader con el tiempo.
• Para el escenario cosole / server, el A10-6700 admite 4 núcleos a 3700MHz (3800MHz con Turbo Core) a largo plazo, al menos con el radeoncontrolador. Probablemente no haya muchas posibilidades de mantener este nivel de rendimiento cuando la GPU tenga algo de trabajo que hacer.
• Parecería que el TDP de 65 W se puede exceder de forma permanente ligeramente a plena carga, pero es difícil saberlo ya que la fuente de alimentación tiene una eficiencia menor a 30 W. Dado que hay indicios claros de que se considera la temperatura (se observó una disipación de potencia máxima de casi 110 W antes de que comenzara a reducirse a 90 W, y también se informaron 2 núcleos a 4300 MHz durante algún tiempo), invertir en enfriamiento de APU puede ser un buena idea. Sin embargo, las placas base limitadas a 65W TDP solo podrán suministrar tanta corriente, por lo que definitivamente habrá un límite estricto impuesto por la APU.
• Si tiene la intención de utilizar una APU Richland para computar en Linux, definitivamente desea utilizar un radeoncontrolador parcheado (si no encuentra inestabilidades, específicamente en combinación con la habilitación de Dynamic Power Management). De lo contrario, no obtendrá el valor total.
• Por extraño que parezca, parece que la mejor configuración sería habilitar Turbo Core y Cool'n'Quiet en el BIOS, pero luego elegir el performanceregulador de escala, al menos si su APU se comporta como la que se probó aquí. Tendrá el mismo consumo de energía que con ondemandun escalado de frecuencia más rápido y menos sobrecarga del kernel para tomar la decisión de escalado.

Agradecimientos

Un agradecimiento especial a Alex Deucher, quien me empujó significativamente en la dirección correcta en bugzilla.kernel.org .

Estoy impresionado por la calidad del radeoncontrolador gratuito y me gustaría agradecer a todo el equipo por mantener este software, que parece haber sido diseñado cuidadosamente. Si radeonno se comportara como lo hace, mi decisión a favor del A10-6700 habría sido sustancialmente errónea.