linux/tools/power, branch v3.8

Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux

2012-12-18T20:34:29Z

Pull powertool update from Len Brown: "This updates the tree w/ the latest version of turbostat, which reports temperature and - on SNB and later - Watts." Fix up semantic merge conflict as per Len. * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: tools: Allow tools to be installed in a user specified location tools/power: turbostat: make Makefile a bit more capable tools/power x86_energy_perf_policy: close /proc/stat in for_every_cpu() tools/power turbostat: v3.0: monitor Watts and Temperature tools/power turbostat: fix output buffering issue tools/power turbostat: prevent infinite loop on migration error path x86 power: define RAPL MSRs tools/power/x86/turbostat: share kernel MSR #defines

tools: Allow tools to be installed in a user specified location

2012-11-30T06:09:45Z

When building x86_energy_perf_policy or turbostat within the confines of a packaging system such as RPM, we need to be able to have it install to the buildroot and not the root filesystem of the build machine. This adds a DESTDIR variable that when set will act as a prefix for the install location of these tools. Signed-off-by: Josh Boyer Signed-off-by: Len Brown

tools/power: turbostat: make Makefile a bit more capable

2012-11-30T06:09:45Z

The turbostat Makefile is pretty simple, its output is placed in the same directory as the source, the install rule has no concept of a prefix or sysroot, and you can set CC to use a specific compiler but not use the more familiar CROSS_COMPILE. By making a few minor changes these limitations are removed while leaving the default behavior matching what it used to be. Example build with these changes: make CROSS_COMPILE=i686-wrs-linux-gnu- DESTDIR=/tmp install or from the tools directory make CROSS_COMPILE=i686-wrs-linux-gnu- DESTDIR=/tmp turbostat_install Signed-off-by: Mark Asselstine Signed-off-by: Len Brown

tools/power x86_energy_perf_policy: close /proc/stat in for_every_cpu()

2012-11-30T06:09:44Z

Instead of returning out of for_every_cpu() we should break out of the loop= which will then tidy up correctly by closing the file /proc/stat. Signed-off-by: Colin Ian King Signed-off-by: Len Brown

tools/power turbostat: v3.0: monitor Watts and Temperature

2012-11-30T06:09:44Z

Show power in Watts and temperature in Celsius when hardware support is present. Intel's Sandy Bridge and Ivy Bridge processor generations support RAPL (Run-Time-Average-Power-Limiting). Per the Intel SDM (Intel® 64 and IA-32 Architectures Software Developer Manual) RAPL provides hardware energy counters and power control MSRs (Model Specific Registers). RAPL MSRs are designed primarily as a method to implement power capping. However, they are useful for monitoring system power whether or not power capping is used. In addition, Turbostat now shows temperature from DTS (Digital Thermal Sensor) and PTM (Package Thermal Monitor) hardware, if present. As before, turbostat reads MSRs, and never writes MSRs. New columns are present in turbostat output: The Pkg_W column shows Watts for each package (socket) in the system. On multi-socket systems, the system summary on the 1st row shows the sum for all sockets together. The Cor_W column shows Watts due to processors cores. Note that Core_W is included in Pkg_W. The optional GFX_W column shows Watts due to the graphics "un-core". Note that GFX_W is included in Pkg_W. The optional RAM_W column on server processors shows Watts due to DRAM DIMMS. As DRAM DIMMs are outside the processor package, RAM_W is not included in Pkg_W. The optional PKG_% and RAM_% columns on server processors shows the % of time in the measurement interval that RAPL power limiting is in effect on the package and on DRAM. Note that the RAPL energy counters have some limitations. First, hardware updates the counters about once every milli-second. This is fine for typical turbostat measurement intervals > 1 sec. However, when turbostat is used to measure events that approach 1ms, the counters are less useful. Second, the 32-bit energy counters are subject to wrapping. For example, a counter incrementing 15 micro-Joule units on a 130 Watt TDP server processor could (in theory) roll over in about 9 minutes. Turbostat detects and handles up to 1 counter overflow per measurement interval. But when the measurement interval exceeds the guaranteed counter range, we can't detect if more than 1 overflow occured. So in this case turbostat indicates that the results are in question by replacing the fractional part of the Watts in the output with "**": Pkg_W Cor_W GFX_W 3** 0** 0** Third, the RAPL counters are energy (Joule) counters -- they sum up weighted events in the package to estimate energy consumed. They are not analong power (Watt) meters. In practice, they tend to under-count because they don't cover every possible use of energy in the package. The accuracy of the RAPL counters will vary between product generations, and between SKU's in the same product generation, and with temperature. turbostat's -v (verbose) option now displays more power and thermal configuration information -- as shown on the turbostat.8 manual page. For example, it now displays the Package and DRAM Thermal Design Power (TDP): cpu0: MSR_PKG_POWER_INFO: 0x2f064001980410 (130 W TDP, RAPL 51 - 200 W, 0.045898 sec.) cpu0: MSR_DRAM_POWER_INFO,: 0x28025800780118 (35 W TDP, RAPL 15 - 75 W, 0.039062 sec.) cpu8: MSR_PKG_POWER_INFO: 0x2f064001980410 (130 W TDP, RAPL 51 - 200 W, 0.045898 sec.) cpu8: MSR_DRAM_POWER_INFO,: 0x28025800780118 (35 W TDP, RAPL 15 - 75 W, 0.039062 sec.) Signed-off-by: Len Brown

tools/power turbostat: fix output buffering issue

2012-11-30T06:09:43Z

In periodic mode, turbostat writes to stdout, but users were un-able to re-direct stdout, eg. turbostat > outputfile would result in an empty outputfile. Signed-off-by: Len Brown

cpupower: IvyBridge (0x3a and 0x3e models) support

2012-11-27T22:07:20Z

Signed-off-by: Thomas Renninger Signed-off-by: Rafael J. Wysocki

cpupower: Provide -c param for cpupower monitor to schedule process on all cores

2012-11-27T22:07:20Z

If an MSR based monitor is run in parallel this is not needed. This is the default case on all/most Intel machines. But when only sysfs info is read via cpupower monitor -m Idle_Stats (typically the case for non root users) or when other monitors are PCI based (AMD), Idle_Stats, read from sysfs can be totally bogus: cpupower monitor -m Idle_Stats PKG |CORE|CPU | POLL | C1-N | C3-N | C6-N 0| 0| 0| 0.00| 0.00| 0.24| 99.81 0| 0| 32| 0.00| 0.00| 0.00| 100.7 ... 0| 17| 20| 0.00| 0.00| 0.00| 173.1 0| 17| 52| 0.00| 0.00| 0.07| 173.0 0| 18| 68| 0.00| 0.00| 0.00| 0.00 0| 18| 76| 0.00| 0.00| 0.00| 0.00 ... With the -c option all cores are woken up and the kernel did update cpuidle statistics before reading out sysfs. This causes some overhead. Therefore avoid if possible, use if needed: cpupower monitor -c -m Idle_Stats PKG |CORE|CPU | POLL | C1-N | C3-N | C6-N 0| 0| 0| 0.00| 0.00| 0.00| 100.2 0| 0| 32| 0.00| 0.00| 0.00| 100.2 ... 0| 8| 8| 0.00| 0.00| 0.00| 99.82 0| 8| 40| 0.00| 0.00| 0.00| 99.81 0| 9| 24| 0.00| 0.00| 0.00| 100.3 0| 9| 56| 0.00| 0.00| 0.00| 100.2 0| 16| 4| 0.00| 0.00| 0.00| 99.75 0| 16| 36| 0.00| 0.00| 0.00| 99.38 ... Signed-off-by: Thomas Renninger Signed-off-by: Rafael J. Wysocki

cpupower tools: Fix warning and a bug with the cpu package count

2012-11-27T22:07:19Z

The pkgs member of cpupower_topology is being used as the number of cpu packages. As the comment in get_cpu_topology notes, the package ids are not guaranteed to be contiguous. So, simply setting pkgs to the value of the highest physical_package_id doesn't actually provide a count of the number of cpu packages. Instead, calculate pkgs by setting it to the number of distinct physical_packge_id values which is pretty easy to do after the core_info structs are sorted. Calculating pkgs this way also has the nice benefit of getting rid of a sign comparison warning that GCC 4.6 was reporting. Signed-off-by: Palmer Cox Signed-off-by: Thomas Renninger Signed-off-by: Rafael J. Wysocki

cpupower tools: Fix malloc of cpu_info structure

2012-11-27T22:07:19Z

The cpu_info member of cpupower_topology was being declared as an unnamed structure. This member was then being malloced using the size of the parent cpupower_topology * the number of cpus. This works because cpu_info is smaller than cpupower_topology. However, there is no guarantee that will always be the case. Making cpu_info its own top level structure (named cpuid_core_info) allows for mallocing the actual size of this structure. This also lets us get rid of a redefinition of the structure in topology.c with slightly different field names. Signed-off-by: Palmer Cox Signed-off-by: Thomas Renninger Signed-off-by: Rafael J. Wysocki