How to make it run------------------You need the pcitutils package (or whatever provides libpci) at runtimeand pcitutils-devel package (or whatever provides /usr/include/pci/pci.h)at compile time.Also a gcc version that provides cpuid.h is needed, but it's in there forsome time already afaik.

Don't forget to use the right branch if you use the git repo:git branch --track cpupowerutils origin/cpupowerutilsgit checkout cpupowerutils

There is one known compile warning in get_cpu_topology, it'son the ToDo list.

Why is there need for another tool?-----------------------------------CPU power consumption vs performance tuning is not aboutCPU frequency switching anymore for quite some time.Deep sleep states, traditional dynamic frequency scaling andhidden turbo/boost frequencies are tight close together anddepend on each other. The first two exist on different architectureslike PPC, Itanium and ARM the latter only on X86.On X86 the APU (CPU+GPU) will only run most efficiently if CPUand GPU has proper power management in place.

Users and Developers want to have *one* tool to get an overview what their system supports and to monitor and debug CPU power management in detail.

The tool should compile and work on as much architectures aspossible.

What is this tool doing?------------------------It provides all features cpufrequtils does.It got enhanced with cpuidle and turbo/boost mode (on X86) statistics.On AMD the exact amount of supported boost states and their frequenciesare shown. On Intel only turbo/boost support is shown.

It got enhanced with a generic HW monitor tool (cpupower monitor).

The generic HW monitor tool is the most powerful enhancement.It is a framework to monitor kernel or HW power statistics.It's easy to extend with additional, architecture or processor modelspecific counters.It's based on turbostat which got merged into the kernel recently:tools/power/x86/turbostat

Additionally there is a monitor to collect kernel idle statistics and display them (separate or together) in the same format. This works on all architectures using the cpuidle kernel framework including different ARMarchitectures and there were patches for powerpc (not in the mainlinekernel yet).This allows to compare kernel and HW statistics on specific workloads andfigure out how the HW performs compared to OS behavior.

Additionally there is an AMD Liano (fam 12h) and Ontario (fam 14h) family specific monitor. This one shows different Package Core (!PC0, PC1, PC7)sleep state statistics directly read out from HW, similar to Nehalemand SandyBridge coutners.The registers are accessed via PCI and therefore can still be read out while cores have been offlined.The Liano/Ontario monitor has one special counter: NBP1 (North Bridge P1).This one always returns 0 or 1, depending on whether the North Bridge P1power state got entered at least once during measure time.Being able to enter NBP1 state also depends on graphics power management.Therefore this counter can be used to verify whether the graphics' driverpower management is working as expected. (E.g. this counter proves thatradeon KMS graphics drivers are missing functionality and NBP1 will onlybe entered when using the fglrx driver).

Kernel Idle_Stats counter is the only one also working without rootprivileges and is architecture independent (should provide info on quitesome ARM models and possibly soon on powerpc as well if cpuidle supportis implemented in the kernel there):