Našel jsem řešení díky tipu od Nilse a pěknému článku.
Ladění na vyžádání CPU DVFS Governor
Regulátor na vyžádání má sadu parametrů k ovládání, když nakopává dynamické frekvenční škálování (nebo DVFS pro dynamické škálování napětí a frekvence). Tyto parametry jsou umístěny pod stromem sysfs:/sys/devices/system/cpu/cpufreq/ondemand/
Jeden z těchto parametrů je up_threshold což, jak název napovídá, je práh (jednotkou je % CPU, nezjistil jsem však, zda se jedná o jádro nebo sloučená jádra), nad kterým naskočí regulátor na vyžádání a začne dynamicky měnit frekvenci.
Změna na 50 % (například) pomocí sudo je jednoduchá:
sudo bash -c "echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold"
Pokud jste root, je možný ještě jednodušší příkaz:
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
Poznámka:tyto změny budou ztraceny po příštím restartu hostitele. Měli byste je přidat do konfiguračního souboru, který se načítá během bootování, jako /etc/init.d/rc.local na Ubuntu.
Zjistil jsem, že můj hostující VM, ačkoli spotřebovával hodně CPU (80–140 %) na hostiteli, rozděloval zátěž na obě jádra, takže žádné jedno jádro nebylo nad 95 %, takže CPU k mému rozhořčení bylo zůstat na 800 MHz. Nyní s výše uvedeným patchem CPU dynamicky mění frekvenci na jádro mnohem rychleji, což lépe vyhovuje mým potřebám, 50 % se zdá být lepší prahová hodnota pro mé využití hostem, váš kilometrový výkon se může lišit.
Volitelně ověřte, zda používáte HPET
Je možné, že některé použitelné, které nesprávně implementují časovače, mohou být ovlivněny DVFS. To může být problém v prostředí hostitele a/nebo hosta, ačkoli hostitel může mít nějaký spletitý algoritmus, který se to pokusí minimalizovat. Moderní CPU však mají novější TSC (Time Stamp Counter), které jsou nezávislé na aktuální frekvenci CPU/jádra, jsou to:konstantní (constant_tsc), invariantní (invariant_tsc) nebo nonstop (nonstop_tsc), viz tento článek Chromium o resynchronizaci TSC pro více informací o každém. Pokud je tedy váš CPU vybaven jedním z těchto TSC, nemusíte HPET nutit. Chcete-li ověřit, zda je váš hostitelský CPU podporuje, použijte podobný příkaz (změňte parametr grep na odpovídající vlastnost CPU, zde testujeme konstantní TSC):
$ grep constant_tsc /proc/cpuinfo
Pokud nemáte jeden z těchto moderních TSC, měli byste buď:
- Aktivní HPET, to je popsáno níže;
- Nepoužívejte CPU DVFS, pokud máte ve virtuálním počítači nějaké aplikace, které se spoléhají na přesné načasování, což je to, které doporučuje Red Hat.
Bezpečným řešením je povolit časovače HPET (podrobnosti viz níže), dotazují se pomaleji než ty TSC (TSC jsou v CPU, vs. HPET jsou v základní desce) a možná nemají přesné (HPET>10MHz; TSC často maximální takt CPU), ale jsou mnohem spolehlivější, zejména v konfiguraci DVFS, kde každé jádro může mít jinou frekvenci. Linux je dost chytrý na to, aby používal nejlepší dostupný časovač, bude spoléhat nejprve na TSC, ale pokud bude příliš nespolehlivý, použije HPET. To funguje dobře na hostitelských (holých kovových) systémech, ale vzhledem k tomu, že ne všechny informace správně exportuje hypervizor, je to pro hostovaný VM spíše problém detekovat špatně se chovající TSC. Trik je pak vynutit použití HPET u hosta, ačkoli byste potřebovali hypervizor, aby tento zdroj hodin hostům zpřístupnil!
Níže naleznete, jak nakonfigurovat a/nebo povolit HPET v Linuxu a FreeBSD.
Konfigurace HPET pro Linux
HPET, neboli vysoce přesný časovač událostí, je hardwarový časovač, který můžete najít ve většině běžných počítačů od roku 2005. Tento časovač lze efektivně používat moderními operačními systémy (linuxové jádro jej podporuje od verze 2.6, stabilní podpora na FreeBSD od nejnovější verze 9.x ale byl představen v 6.3), aby poskytoval konzistentní časování pro správu napájení CPU. Umožňuje vytvářet také jednodušší implementace plánovače bez tick-less.
HPET je v zásadě jako bezpečnostní bariéra, která i když má hostitel aktivní DVFS, události načasování hostitele a hosta budou méně ovlivněny.
Existuje dobrý článek od IBM týkající se povolení HPET, vysvětluje, jak ověřit, který hardwarový časovač vaše jádro používá a které jsou dostupné. Zde uvádím stručné shrnutí:
Kontrola dostupných hardwarových časovačů:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
Kontrola aktuálně aktivního časovače:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
Jednodušší způsob, jak vynutit použití HPET, pokud jej máte k dispozici, je upravit váš zavaděč tak, aby jej povolil (od jádra 2.6.16). Tato konfigurace je závislá na distribuci, takže se prosím podívejte do své vlastní distribuční dokumentace, abyste ji správně nastavili. Měli byste povolit hpet=enable nebo clocksource=hpet na zaváděcí řádce jádra (záleží opět na verzi jádra nebo distribuci, nenašel jsem žádné ucelené informace).
Tím se ujistěte, že host používá časovač HPET.
Poznámka:v mém jádře 3.5 se zdá, že Linux automaticky sbírá časovač hpet.
Konfigurace hostujícího HPET FreeBSD
Na FreeBSD můžete zkontrolovat, které časovače jsou k dispozici spuštěním:
sysctl kern.timecounter.choice
Aktuálně zvolený časovač lze ověřit pomocí:
sysctl kern.timecounter.hardware
Zdá se, že FreeBSD 9.1 automaticky preferuje HPET před jiným poskytovatelem časovače.
Úkol:jak vynutit HPET na FreeBSD.
Export Hypervisor HPET
Zdá se, že KVM exportuje HPET automaticky, když ho hostitel podporuje. Pro hosta Linuxu však budou preferovat jiné automaticky exportované hodiny, které jsou kvm-clock (paravirtualizovaná verze hostitelského TSC). Někteří lidé hlásí potíže s preferovanými hodinami, váš počet najetých kilometrů se může lišit. Pokud chcete v hostovi vynutit HPET, podívejte se na výše uvedenou sekci.
VirtualBox standardně neexportuje hodiny HPET do hosta a v GUI to není možné. Musíte použít příkazový řádek a ujistit se, že je virtuální počítač vypnutý. příkaz je:
./VBoxManage modifyvm "VM NAME" --hpet on
Pokud bude host po výše uvedené změně nadále vybírat jiný zdroj než HPET, přečtěte si prosím výše uvedenou sekci, jak přinutit jádro, aby jako zdroj použilo hodiny HPET.
Není to host, kdo spouští upscale – to musí udělat hostitel. Musíte tedy snížit příslušnou úroveň spouštění na hostiteli.
na hostiteli vypadá cpu kvm jako proces. Mechanismus škálování nesleduje procesy, pouze celkovou spotřebu procesoru.
a obecně je nejlepší praxí zakázat škálování procesoru/omezování/atd. při spuštění virtuálních počítačů