He encontrado la solución gracias al consejo de Nils y un buen artículo.
Ajuste del bajo demanda Gobernador de CPU DVFS
El gobernador bajo demanda tiene un conjunto de parámetros para controlar cuándo está activando el escalado de frecuencia dinámico (o DVFS para el escalado 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 sugiere el nombre, es un umbral (la unidad es el % de CPU, aunque no he averiguado si esto es por núcleo o núcleos combinados) 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 es 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 superaba el 95 %, por lo que la CPU, para mi exasperación, estaba permanecer en 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 invitados, su kilometraje puede variar.
Opcionalmente, verifique si está utilizando HPET
Es posible que algunos aplicables que implementan incorrectamente los temporizadores se vean afectados por DVFS. Esto puede ser un problema en el entorno del anfitrión y/o del invitado, aunque el anfitrión puede tener algún algoritmo enrevesado para tratar de minimizar esto. Sin embargo, la CPU moderna tiene un TSC (contador de marca de tiempo) más nuevo que es independiente de la frecuencia actual de la CPU/núcleo, estos son:constante (constant_tsc), invariante (invariant_tsc) o continuo (nonstop_tsc), consulte este artículo de Chromium sobre la resincronización de TSC para obtener 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):
$ grep constant_tsc /proc/cpuinfo
Si no tiene uno de estos TSC modernos, debe:
- HPET activo, esto se describe a continuación;
- No utilice CPU DVFS si tiene aplicaciones en la máquina virtual que dependen de una temporización precisa, que es la recomendada por Red Hat.
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 están en la placa base) y quizás no tengan precisión (HPET> 10 MHz; 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, primero se basará en el TSC, pero si se encuentra demasiado poco confiable, usará el HPET. Esto funciona bien en los sistemas host (bare metal), pero debido a que el hipervisor no exporta toda la información correctamente, esto es más un desafío para que la máquina virtual invitada detecte el TSC que se comporta mal. El truco consiste entonces 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 HPET de Linux
HPET, o temporizador de eventos de alta precisión, es un temporizador de hardware que puede encontrar en la mayoría de las PC básicas desde 2005. Este temporizador puede ser utilizado de manera eficiente por los sistemas operativos modernos (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 consistente invariablemente a la administración de energía de la CPU. También permite crear implementaciones de planificador sin ticks más sencillas.
Básicamente, HPET es como una barrera de seguridad que, incluso si el anfitrión tiene DVFS activo, los eventos de tiempo del anfitrión y del 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 kernel y cuáles están disponibles. Ofrezco 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 cargador de arranque para solicitar que lo habilite (desde el kernel 2.6.16). Esta configuración depende de la distribución, así que consulte su propia documentación de distribución para configurarla correctamente. Debe habilitar hpet=enable o clocksource=hpet en la línea de inicio 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 activar automáticamente el temporizador hpet.
Configuración de HPET invitado de FreeBSD
En FreeBSD se puede comprobar qué temporizadores están disponibles ejecutando:
sysctl kern.timecounter.choice
El temporizador seleccionado actualmente se puede verificar con:
sysctl kern.timecounter.hardware
FreeBSD 9.1 parece preferir automáticamente HPET a otros proveedores de temporizadores.
Todo:cómo forzar HPET en FreeBSD.
Exportación HPET de hipervisor
KVM parece exportar HPET automáticamente cuando el host tiene soporte para ello. Sin embargo, para los invitados de Linux, preferirán el otro reloj exportado automáticamente, que es kvm-clock (una versión paravirtualizada del host TSC). Algunas personas reportan problemas con el reloj preferido, su millaje puede variar. Si desea forzar HPET en el huésped, 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 máquina virtual esté apagada. el comando es:
./VBoxManage modifyvm "VM NAME" --hpet on
Si el invitado sigue seleccionando otra fuente que no sea HPET después del cambio anterior, consulte la sección anterior sobre cómo obligar al kernel a usar el reloj HPET como fuente.
No es el huésped el que desencadena el aumento de nivel:el anfitrión debe hacer esto. Por lo tanto, debe reducir el nivel de activación correspondiente en el host.
en el host, una cpu kvm parece un proceso. El mecanismo de escalado no supervisa los procesos, solo el consumo general de la CPU.
y, en general, es una buena práctica deshabilitar el escalado/aceleración/etc. de la CPU cuando se ejecutan máquinas virtuales