Observación:
Tengo un servidor HP con una CPU AMD de doble núcleo (Turion II Neo N40L) que puede escalar frecuencias de 800 a 1500 MHz. La escala de frecuencia funciona bajo FreeBSD 9 y bajo Ubuntu 12.04 con el kernel 3.5 de Linux. Sin embargo, cuando coloco FreeBSD 9 en un entorno KVM encima de Ubuntu, la escala de frecuencia no funciona. El invitado (por lo tanto, FreeBSD) no detecta las frecuencias mínima y máxima y, por lo tanto, no escala nada cuando la ocupación de la CPU aumenta. En el host (por lo tanto, Ubuntu), el proceso KVM utiliza entre el 80 y el 140% de los recursos de la CPU, pero no ocurre escala de frecuencia, la frecuencia se mantiene en 800 MHz, aunque cuando ejecuto cualquier otro proceso en el mismo cuadro de Ubuntu, el gobernador a pedido rápidamente ¡escala la frecuencia a 1500 MHz!
Preocupación y pregunta:
no entiendo cómo la CPU está quizás virtualizada, y si depende del huésped realizar el escalado adecuado. ¿Requiere que algunas características de la CPU estén expuestas al huésped para que esto funcione?
Apéndice:
La siguiente nota de lanzamiento de Red Hat tiende a sugerir que la escala de frecuencia funciona incluso en un entorno virtualizado (consulte el capítulo 6.2.2 y 6.2.3), aunque la nota no aborda con qué tecnología de virtualización funciona (kvm, xen , etc.?)
Para información, el cpufreq-info
resultado en Ubuntu es:
$ cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to [email protected], please.
analyzing CPU 0:
driver: powernow-k8
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 8.0 us.
hardware limits: 800 MHz - 1.50 GHz
available frequency steps: 1.50 GHz, 1.30 GHz, 1000 MHz, 800 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 800 MHz and 1.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz.
cpufreq stats: 1.50 GHz:14.79%, 1.30 GHz:1.07%, 1000 MHz:0.71%, 800 MHz:83.43% (277433)
analyzing CPU 1:
driver: powernow-k8
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 8.0 us.
hardware limits: 800 MHz - 1.50 GHz
available frequency steps: 1.50 GHz, 1.30 GHz, 1000 MHz, 800 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 800 MHz and 1.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz.
cpufreq stats: 1.50 GHz:14.56%, 1.30 GHz:1.06%, 1000 MHz:0.79%, 800 MHz:83.59% (384089)
La razón por la que quiero que esta característica funcione es: ahorrar energía, correr más silenciosamente (menos calor) y también simple curiosidad para comprender mejor por qué esto no funciona y cómo hacerlo funcionar.
cpufreq-info
en el sistema operativo host, probablemente se quejará de que no hay un controlador disponible.cpufreq-info
no se queja y muestra información adecuada, por lo que la CPU es totalmente compatible (¡por supuesto, de alguna manera! El controlador utilizado es powernow-k8, que también es lógico.Respuestas:
He encontrado la solución gracias a la sugerencia dada por Nils y un buen artículo .
Ajuste del gobernador de CPU DVFS bajo demanda
El gobernador bajo demanda tiene un conjunto de parámetros para controlar cuando está activando la escala de frecuencia dinámica (o DVFS para la escala de frecuencia y voltaje dinámico). Esos parámetros se encuentran debajo del árbol sysfs:
/sys/devices/system/cpu/cpufreq/ondemand/
Uno de estos parámetros es
up_threshold
que, como su nombre indica, es un umbral (la unidad es el% de CPU, aunque no he descubierto si es por núcleo o núcleos fusionados) por encima del cual el gobernador bajo demanda se activa y comienza a cambiar dinámicamente la frecuencia.Cambiarlo al 50% (por ejemplo) usando sudo es simple:
sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold"
Si eres root, es posible un comando aún más simple:
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
Nota: esos cambios se perderán después del próximo reinicio del host. Debe agregarlos a un archivo de configuración que se lee durante el arranque, como
/etc/init.d/rc.local
en Ubuntu.Descubrí que mi máquina virtual invitada, aunque consumía una gran cantidad de CPU (80-140%) en el host, estaba distribuyendo la carga en ambos núcleos, por lo que ningún núcleo individual estaba por encima del 95%, por lo que la CPU, para mi exasperación, era quedándose a 800 MHz. Ahora con el parche anterior, la CPU cambia dinámicamente su frecuencia por núcleo mucho más rápido, lo que se adapta mejor a mis necesidades, el 50% parece un mejor umbral para el uso de mis invitados, su kilometraje puede variar.
Opcionalmente, verifique si está utilizando HPET
Es posible que algunos de los aplicables que implementan temporizadores incorrectamente puedan verse afectados por DVFS. Esto puede ser un problema en el entorno host y / o invitado, aunque el host puede tener algún algoritmo complicado para intentar minimizar esto. Sin embargo, la CPU moderna tiene un TSC (Contador de sello de tiempo) más nuevo que es independiente de la frecuencia actual de CPU / núcleo, que son: constante (constant_tsc), invariante (invariant_tsc) o sin parar (nonstop_tsc), consulte este artículo de Chromium sobre la resincronización de TSC Para más información sobre cada uno. Entonces, si su CPU está equipada con uno de estos TSC, no necesita forzar HPET. Para verificar si su CPU host los admite, use un comando similar (cambie el parámetro grep a la función de CPU correspondiente, aquí probamos el TSC constante):
Si no tiene uno de estos TSC modernos, debe:
Una solución segura es habilitar los temporizadores HPET (consulte a continuación para obtener más detalles), son más lentos para consultar que los TSC (TSC están en la CPU, frente a HPET en la placa base) y tal vez no tienen precisión (HPET> 10MHz; TSC a menudo el reloj máximo de la CPU), pero son mucho más confiables, especialmente en una configuración DVFS donde cada núcleo podría tener una frecuencia diferente. Linux es lo suficientemente inteligente como para usar el mejor temporizador disponible, dependerá primero del TSC, pero si se encuentra poco confiable, usará el HPET. Esto funciona bien en los sistemas host (bare metal), pero debido a que no toda la información exportada correctamente por el hipervisor, esto es más un desafío para la máquina virtual invitada para detectar TSC de mal comportamiento. El truco consiste en forzar el uso de HPET en el invitado, ¡aunque necesitaría el hipervisor para que esta fuente de reloj esté disponible para los invitados!
A continuación puede encontrar cómo configurar y / o habilitar HPET en Linux y FreeBSD.
Configuración de Linux HPET
HPET, o temporizador de eventos de alta precisión, es un temporizador de hardware que puede encontrar en la mayoría de las PC desde 2005. Este sistema operativo moderno puede usar este temporizador de manera eficiente (el kernel de Linux lo admite desde 2.6, soporte estable en FreeBSD desde la última versión 9.x) pero se introdujo en 6.3 ) para proporcionar un tiempo constante invariablemente a la administración de energía de la CPU. Permite construir también implementaciones de planificador sin tick más fáciles .
Básicamente, HPET es como una barrera de seguridad que, incluso si el host tiene DVFS activo, los eventos de temporización del host y el invitado se verán menos afectados.
Hay un buen artículo de IBM sobre la habilitación de HPET , explica cómo verificar qué temporizador de hardware está usando su núcleo y cuáles están disponibles. Proporciono aquí un breve resumen:
Comprobación de los temporizadores de hardware disponibles:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
Comprobación del temporizador activo actual:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
Una forma más sencilla de forzar el uso de HPET si lo tiene disponible es modificar su gestor de arranque para solicitar habilitarlo (desde el kernel 2.6.16). Esta configuración depende de la distribución, por lo tanto, consulte su propia documentación de distribución para configurarla correctamente. Debe habilitar
hpet=enable
oclocksource=hpet
en la línea de arranque del kernel (esto nuevamente depende de la versión o distribución del kernel, no encontré ninguna información coherente).Esto asegura que el invitado esté usando el temporizador HPET.
Nota: en mi kernel 3.5, Linux parece recoger automáticamente el temporizador hpet.
Configuración de HPET invitado de FreeBSD
En FreeBSD se puede verificar qué temporizadores están disponibles ejecutando:
sysctl kern.timecounter.choice
El temporizador elegido actualmente se puede verificar con:
sysctl kern.timecounter.hardware
FreeBSD 9.1 parece preferir automáticamente HPET a otro proveedor de temporizadores.
Todo: cómo forzar HPET en FreeBSD.
Exportación de hipervisor HPET
KVM parece exportar HPET automáticamente cuando el host lo admite. Sin embargo, para los invitados de Linux, preferirán el otro reloj exportado automáticamente, que es kvm-clock (una versión paravirtualizada del TSC del host). Algunas personas informan problemas con el reloj preferido, su millaje puede variar. Si desea forzar HPET en el invitado, consulte la sección anterior.
VirtualBox no exporta el reloj HPET al invitado de forma predeterminada, y no hay ninguna opción para hacerlo en la GUI. Debe usar la línea de comando y asegurarse de que la VM esté apagada. el comando es:
Si el invitado continúa seleccionando otra fuente que no sea HPET después del cambio anterior, consulte la sección anterior sobre cómo obligar al núcleo a usar el reloj HPET como fuente.
fuente
No es el invitado el que desencadena el exclusivo; el host debe hacer esto. Por lo tanto, debe reducir el nivel de activación correspondiente en el host.
fuente
sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold"
Fuente: ivanlam.info/blog/2012/04/26/…cpuspeed
se encuentra en / etc / sysconfig / cpuspeed para que dicho cambio sea permanente. En mi caso, tenía un VBox-VM con solo una CPU (físicamente dual-core). Tuve que bajar el nivel al 45% para obtener el efecto exclusivo en la VM.En el host, una CPU KVM parece un proceso. El mecanismo de escala no observa los procesos, solo el consumo general de la CPU.
y generalmente es una buena práctica deshabilitar el escalado / aceleración de la CPU / etc. cuando se ejecutan máquinas virtuales
fuente