Ho trovato la soluzione grazie al suggerimento di Nils ea un bell'articolo.
Ottimizzazione dell'ondemand Regolatore DVFS della CPU
Il regolatore ondemand ha una serie di parametri da controllare quando avvia il ridimensionamento dinamico della frequenza (o DVFS per il ridimensionamento dinamico della tensione e della frequenza). Questi parametri si trovano sotto l'albero sysfs:/sys/devices/system/cpu/cpufreq/ondemand/
Uno di questi parametri è up_threshold che, come suggerisce il nome, è una soglia (l'unità è % della CPU, ma non ho scoperto se si tratta di core o core uniti) al di sopra della quale entra in gioco il governatore ondemand e inizia a cambiare dinamicamente la frequenza.
Cambiarlo al 50% (per esempio) usando sudo è semplice:
sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold"
Se sei root, è possibile un comando ancora più semplice:
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
Nota:tali modifiche andranno perse dopo il successivo riavvio dell'host. Dovresti aggiungerli a un file di configurazione che viene letto durante l'avvio, come /etc/init.d/rc.local su Ubuntu.
Ho scoperto che la mia VM ospite, pur consumando molta CPU (80-140%) sull'host, distribuiva il carico su entrambi i core, quindi nessun singolo core era superiore al 95%, quindi la CPU, con mia esasperazione, era rimanendo a 800 MHz. Ora con la patch di cui sopra, la CPU cambia dinamicamente la frequenza per core molto più velocemente, il che si adatta meglio alle mie esigenze, il 50% sembra una soglia migliore per il mio utilizzo da parte degli ospiti, il tuo chilometraggio può variare.
Facoltativamente, verifica se stai utilizzando HPET
È possibile che alcune applicazioni che implementano in modo errato i timer possano essere influenzate da DVFS. Questo può essere un problema nell'ambiente host e/o guest, sebbene l'host possa avere un algoritmo contorto per cercare di minimizzarlo. Tuttavia, le CPU moderne hanno TSC (Time Stamp Counter) più recenti che sono indipendenti dall'attuale frequenza CPU/core, ovvero:costante (constant_tsc), invariante (invariant_tsc) o non-stop (nonstop_tsc), vedere questo articolo di Chromium sulla risincronizzazione TSC per ulteriori informazioni su ciascuno. Quindi, se la tua CPU è dotata di uno di questi TSC, non è necessario forzare HPET. Per verificare se la tua CPU host li supporta, usa un comando simile (modifica il parametro grep con la funzione della CPU corrispondente, qui testiamo per il TSC costante):
$ grep constant_tsc /proc/cpuinfo
Se non hai uno di questi moderni TSC, dovresti:
- HPET attivo, questo è descritto qui di seguito;
- Non utilizzare CPU DVFS se nella VM sono presenti applicazioni che si basano su un timing preciso, che è quello consigliato da Red Hat.
Una soluzione sicura è abilitare i timer HPET (vedi sotto per maggiori dettagli), sono più lenti da interrogare rispetto a quelli TSC (TSC sono nella CPU, contro HPET sono nella scheda madre) e forse non hanno precisione (HPET> 10MHz; TSC spesso il massimo clock della CPU) ma sono molto più affidabili soprattutto in una configurazione DVFS in cui ogni core potrebbe avere una frequenza diversa. Linux è abbastanza intelligente da utilizzare il miglior timer disponibile, si baserà prima sul TSC, ma se ritenuto troppo inaffidabile, utilizzerà quello HPET. Funziona bene sui sistemi host (bare metal), ma a causa del fatto che non tutte le informazioni vengono esportate correttamente dall'hypervisor, questa è più una sfida per la VM guest per rilevare il cattivo comportamento di TSC. Il trucco è quindi forzare l'utilizzo di HPET nel guest, anche se sarebbe necessario l'hypervisor per rendere disponibile questa sorgente di clock ai guest!
Di seguito puoi trovare come configurare e/o abilitare HPET su Linux e FreeBSD.
Configurazione Linux HPET
HPET, o timer di eventi ad alta precisione, è un timer hardware che puoi trovare nella maggior parte dei PC di fascia alta dal 2005. Questo timer può essere utilizzato in modo efficiente dai moderni sistemi operativi (il kernel Linux lo supporta dalla versione 2.6, supporto stabile su FreeBSD dall'ultima versione 9.x ma è stato introdotto in 6.3) per fornire invariabilmente tempi coerenti alla gestione dell'alimentazione della CPU. Permette di creare anche implementazioni di scheduler senza tick più semplici.
Fondamentalmente HPET è come una barriera di sicurezza che anche se l'host ha DVFS attivo, gli eventi temporali di host e guest saranno meno influenzati.
C'è un buon articolo di IBM sull'abilitazione di HPET, spiega come verificare quale timer hardware sta usando il tuo kernel e quali sono disponibili. Fornisco qui un breve riassunto:
Controllo dei timer hardware disponibili:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
Controllo del timer attivo corrente:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
Un modo più semplice per forzare l'utilizzo di HPET se lo si ha a disposizione è modificare il boot loader per chiedere di abilitarlo (a partire dal kernel 2.6.16). Questa configurazione dipende dalla distribuzione, quindi fai riferimento alla documentazione della tua distribuzione per impostarla correttamente. Dovresti abilitare hpet=enable o clocksource=hpet sulla riga di avvio del kernel (anche questo dipende dalla versione o dalla distribuzione del kernel, non ho trovato alcuna informazione coerente).
Ciò assicura che l'ospite stia utilizzando il timer HPET.
Nota:sul mio kernel 3.5, Linux sembra rilevare automaticamente il timer hpet.
Configurazione HPET ospite di FreeBSD
Su FreeBSD è possibile verificare quali timer sono disponibili eseguendo:
sysctl kern.timecounter.choice
Il timer attualmente scelto può essere verificato con:
sysctl kern.timecounter.hardware
FreeBSD 9.1 sembra preferire automaticamente HPET rispetto ad altri fornitori di timer.
Todo:come forzare HPET su FreeBSD.
Esportazione HPET hypervisor
KVM sembra esportare HPET automaticamente quando l'host lo supporta. Tuttavia, per i guest Linux preferiranno l'altro orologio esportato automaticamente che è kvm-clock (una versione paravirtualizzata dell'host TSC). Alcune persone segnalano problemi con l'orologio preferito, il tuo chilometraggio può variare. Se vuoi forzare HPET nel guest, fai riferimento alla sezione precedente.
VirtualBox non esporta l'orologio HPET nel guest per impostazione predefinita e non esiste alcuna opzione per farlo nella GUI. È necessario utilizzare la riga di comando e assicurarsi che la VM sia spenta. il comando è:
./VBoxManage modifyvm "VM NAME" --hpet on
Se il guest continua a selezionare un'origine diversa da HPET dopo la modifica di cui sopra, fai riferimento alla sezione precedente su come forzare il kernel a utilizzare l'orologio HPET come origine.
Non è l'ospite che attiva l'upscale:l'host deve farlo. Quindi devi abbassare il livello di trigger corrispondente sull'host.
sull'host, una cpu kvm sembra un processo. Il meccanismo di ridimensionamento non controlla i processi, solo il consumo complessivo della CPU.
ed è generalmente la migliore pratica disabilitare il ridimensionamento della cpu/throttling/etc durante l'esecuzione di VM