Talk:Xen power management

xen_acpi_processor module

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, thus xenpm get-cpufreq-states shows nothing and xenpm get-cpuidle-states shows only C0 and C1.

After a modprobe xen_acpi_processor I see frequencies in xenpm get-cpufreq-states, and xenpm get-cpuidle-states shows a C2 state as well. Also running 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).

Suggested improvements:

• add a note about modprobe xen_acpi_processor to the hypervisor based cpufreq entry
• add a note on what happens when modprobe xen_acpi_processor is not used: empty cpufreq list, limited C states
• add a note to the cpuidle entry that without xen_acpi_processor the max C state could be limited
• improve the xenpm tool to show a hint that maybe you should load the xen_acpi_processor module 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).