kernel/linux.git/tools/power/cpupower/utils, branch v3.13.3

cpupower: Fix segfault due to incorrect getopt_long arugments

2013-12-17T19:29:30+00:00

If a user calls 'cpupower set --perf-bias 15', the process will end with a SIGSEGV in libc because cpupower-set passes a NULL optarg to the atoi call. This is because the getopt_long structure currently has all of the options as having an optional_argument when they really have a required argument. We change the structure to use required_argument to match the short options and it resolves the issue. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1000439 Signed-off-by: Josh Boyer Cc: Dominik Brodowski Cc: Thomas Renninger Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds

tools: cpupower: fix wrong err msg not supported vs not available

2013-11-25T22:10:50+00:00

idlestates in sysfs are counted from 0. This fixes a wrong error message. Current behavior on a machine with 4 sleep states is: cpupower idle-set -e 4 Idlestate 4 enabled on CPU 0 -----Wrong--------------------- cpupower idle-set -e 5 Idlestate enabling not supported by kernel -----Must and now will be ----- cpupower idle-set -e 5 Idlestate 6 not available on CPU 0 ------------------------------- cpupower idle-set -e 6 Idlestate 6 not available on CPU 0 Signed-off-by: Thomas Renninger Signed-off-by: Rafael J. Wysocki

cpupower: Add Haswell family 0x45 specific idle monitor to show PC8,9,10 states

2013-07-04T23:52:19+00:00

This specific processor supports 3 new package sleep states. Provide a monitor, so that the user can see their usage. Signed-off-by: Thomas Renninger Signed-off-by: Rafael J. Wysocki

cpupower: Haswell also supports the C-states introduced with SandyBridge

2013-07-04T23:52:19+00:00

Add Haswell model numbers to snb_register() as it also supports the C-states introduced in SandyBridge processors. [rjw: Changelog] Signed-off-by: Thomas Renninger Signed-off-by: Rafael J. Wysocki

cpupower: Introduce idle-set subcommand and C-state enabling/disabling

2013-07-04T23:52:19+00:00

Example: cpupower idle-set -d 3 will disable C-state 3 on all processors (set commands are active on all CPUs by default), same as: cpupower -c all idle-set -d 3 Signed-off-by: Thomas Renninger Signed-off-by: Rafael J. Wysocki

cpupower: Implement disabling of cstate interface

2013-07-04T23:52:19+00:00

Latest kernel allows to disable C-states via: /sys/devices/system/cpu/cpuX/cpuidle/stateY/disable This patch provides lower level sysfs access functions to make use of this interface. A later patch will implement the higher level stuff. Signed-off-by: Thomas Renninger Signed-off-by: Rafael J. Wysocki

cpupower: Make idlestate usage unsigned

2013-07-04T23:52:19+00:00

Use unsigned int as the data type for some variables related to CPU idle states which allows the code to be simplified slightly. [rjw: Changelog] Signed-off-by: Thomas Renninger Signed-off-by: Rafael J. Wysocki

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

2012-11-27T22:07:20+00:00

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:20+00:00

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:19+00:00

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