Talk:Xen power management
There is a lot of information in this page, but it is missing an important piece of information: how to actually enable cpufreq and deep C states in a hypervisor-based cpufreq. Although it lists a lot of boot flags to fine-tune/choose the behaviour, they are not actually needed on Xen 4.4 to enable power management: the hypervisor based cpufreq and cpuidle is the default without any flags (as the article mentions, but using a revision control number instead of Xen release versions).
By default (on Debian Jessie with kernel 3.16 and a Fam 21 AMD CPU) the xen_acpi_processor module is not loaded,
xenpm get-cpufreq-states shows nothing and
xenpm get-cpuidle-states shows only C0 and C1.
modprobe xen_acpi_processor I see frequencies in
xenpm get-cpufreq-states, and
xenpm get-cpuidle-states shows a C2 state as well.
sensors shows 30-60W on
fam15h_power-pci-00c4 instead of a constant 100W+, and the CPU fan is much quieter (as it used to be without Xen).
- add a note about
modprobe xen_acpi_processorto the hypervisor based cpufreq entry
- add a note on what happens when
modprobe xen_acpi_processoris not used: empty cpufreq list, limited C states
- add a note to the cpuidle entry that without
xen_acpi_processorthe max C state could be limited
- improve the xenpm tool to show a hint that maybe you should load the
xen_acpi_processormodule when it detects that:
- hypervisor based cpufreq is used
- the cpufreq list is empty / the module is not loaded
IMHO the default behaviour of not loading
xen_acpi_processor is good because frequency scaling can have a negative impact on performance due to latencies and it also introduces a lot of noise when running benchmarks,
so that shouldn't be changed (at least that is my experience when using the governors in the Linux kernel, I haven't measured the impact of using the governors in Xen).