pyamsoft / pstate-frequency Goto Github PK

I'm running Ubuntu 14.10 64bit and pstate-frequency fails to build for me. Here's the complete log:

CFLAGS  =  -DDEBUG=0 -DVERSION="0.r.46.eb0ad58[cc]" -std=c99 -O2 -Wall -Wextra -Werror -Wmissing-prototypes -Wunreachable-code -I.
LDFLAGS =  -Wl,-O2,--sort-common,--as-needed,-z,relro,-s
CC      =  cc
cc -c src/mhz.c -o obj/mhz.o
cc -c src/cpu.c -o obj/cpu.o
cc -c src/main.c -o obj/main.o
src/cpu.c: In function ‘pyam_cpu_internal_get’:
src/cpu.c:365:5: error: ignoring return value of ‘getline’, declared with attribute warn_unused_result [-Werror=unused-result]
     getline(&line, &n, file);
     ^
src/cpu.c: In function ‘pyam_cpu_get_file_contents_str’:
src/cpu.c:96:5: error: ignoring return value of ‘getline’, declared with attribute warn_unused_result [-Werror=unused-result]
     getline(&line, &n, file);
     ^
src/cpu.c: In function ‘pyam_cpu_get_number’:
src/cpu.c:119:9: error: ignoring return value of ‘system’, declared with attribute warn_unused_result [-Werror=unused-result]
         system(command);
         ^
src/cpu.c:120:9: error: ignoring return value of ‘system’, declared with attribute warn_unused_result [-Werror=unused-result]
         system(readable);
         ^
cc1: all warnings being treated as errors
Makefile:23: recipe for target 'obj/cpu.o' failed
make: *** [obj/cpu.o] Error 1
make: *** Waiting for unfinished jobs....

Add support for reading and writing the current governor as well as the block device io scheduling policy

Allow the disabling and enabling of turbo through the

/sys/devices/system/cpu/cpufreq/boost

file

Unsure where you'd want this in the repo, so including a quick RPM spec below.

Name:      pstate-frequency
Version:   3.4.0
Release:   1
License:   MIT
Summary:   Easily control Intel p-state driver on Linux
Url:       https://pyamsoft.github.io/pstate-frequency
Group:     System
Source0:   https://github.com/pyamsoft/%{name}/archive/%{version}.tar.gz#/%{name}-%{version}.tar.gz
Requires:  kernel-tools
Requires:  coreutils
Requires:  grep
BuildRoot: %{_tmppath}/%{name}-%{version}-build

%description
Pstate-frequency is able to adjust the Intel p-state driver values for the minimum and maximum scaling frequencies and the state of turbo boost.

%prep
%setup -q

%install
make PREFIX=%{_prefix} DESTDIR=%{buildroot} INCLUDE_SYSTEMD_UNIT=0 INCLUDE_BASH_COMPLETION=0 INCLUDE_UDEV_RULE=0 install

%clean
rm -rf %{buildroot}

%files
%defattr(-,root,root,-)
%{_bindir}/%{name}
%doc %{_docdir}/%{name}/README.md
%doc %{_docdir}/%{name}/LICENSE

%changelog
* Wed Apr 20 2016 3.4.0-1
- Initial release (v3.4.0-1)

appears quite a few time in the output of --help

Update the descriptions and examples in the README to be up to date with the new additions to pstate-frequency.

branch dev: project/src/main.cpp line 102

• newMin = (newMin => newMax
• newMin = (newMin >= newMax

The pstate-driver does not respect the settings for minimum, and maximum performance percentages. As a result, even when setting the maximum to be low, the driver will sometimes still run at a max frequency. It also will not respect settings for no_turbo.

This is due in part to the fact that the max cpu_frequency is defined in

/sys/devices/system/cpu/cpu#/cpufreq/scaling_max_frequency

as the turbo boosted frequency max.
The acpi-cpufreq driver reports the proper frequency and the rules that are set are observed by the driver and cpu frequencies.

Just wanted to say thanks, man. Loved the detailed information on README.md. Thanks!

I don't have an AMD CPU that will use amd-pstate so this may need to be a read the docs and rpay for success kind of situation

After issuing a

# pstate-frequency -S -p 0 (auto)

my values are set as if the power source were not connected (Turbo OFF, governor: powersave). Although the powersource is connected.

Manully specifying pstate-frequency -S -g performance and pstate-frequency -S -t 0 sets the desired values.

This happens with a Lenovo Thinkpad X250 which is docked into an UltraDock Docking Station (with power cord attached).

Problem

Please, take a quick look at this screenshot (and I mean a quick look! don't bother reading the small numbers yet):

By just the looks alone, it looks like the Short Term value is set lower than the Long Term value. After all, the little circular handle for the Short Term is more to the left than the knob for the Long Term. However, if you spend enough time looking at it, you can read the numbers and notice the Short Term is set to 66W, while Long Term is set to 50W.

This becomes clear when we move those sliders to their extremes:

One slider goes up to 200W, while the other only goes to 100W. However, they are both displayed at the same length, so they look like they cover the same range.

Solutions

The smaller range could have a shorter slider. In this case, half of the size. (The actual dimensions should be calculated based on the limits for the current system.)

Alternatively, both sliders could be rendered at full length, but the range after a certain amount could be disabled. Not sure if the widget supports that.

As an yet another idea, both handles could be rendered on the same slider. I'm assuming the Short Term value shouldn't ever be lower than the Long Term value, as that might be nonsensical. If that's the case, both values could be combined into a "range-slider", one with two handles, where the left-most handle is always the Long Term and the right-most is always the Short Term. (Note: this is just a guess based on my assumptions, please correct me!)

When I type "sudo pstate-frequency --set <50%>" into the terminal, it returns "bash: syntax error near unexpected token `newline'." Am I not correctly writing out the code? Perhaps write how to type the code exactly in the README file.

Thanks in advance.

I see that pstate-frequency uses its own governors (powersave, performance and max-performance) and it doesn't changes actual CPU governors (performance and powersave only for Intel P-State). Why exactly is that? And do you plan to allow pstate-frequency to actually change the Intel P-state CPU governor?

I want to write about pstate-frequency on WebUpd8 but I find this confusing... so some clarifications would be nice. Thanks!

I have to switch those two lines to make the turbo setting stick:

Ubuntu 14.10: I tried to change the power plan via "pstate-frequency --set --plan max-performance" and I got this error:

wrmsr: open: No such file or directory

This was fixed after running:

sudo modprobe msr

Maybe you should add this to the readme?

P.s.: thanks for this tool, I find it very useful!

I have this CPU:
http://ark.intel.com/products/71670/Intel-Core-i7-3632QM-Processor-6M-Cache-up-to-3_20-GHz-BGA

Processor Base Frequency 2.2 GHz
Max Turbo Frequency 3.2 GHz

The difference between the non-turbo and turbo frequency makes a huge difference.

The question may be a bit unrelated, but if I am to use the max-performance power plan instead, does it work such that is the best plan possible? With that I mean that i7z says:

Max TURBO Multiplier (if Enabled) with 1/2/3/4 Cores is 32x/31x/29x/29x

If all cores are set to the highest turbo boost frequency, do I still get the largest multiplier and thus the best single core performance on at least one core?

Is this common enough that instead of acpi-cpufreq or intel_pstate users see this scheduler instead?

Since this is an acpi-cpufreq like scheduler I assume we can use a lot of the existing acpi cpufreq paths and logic and just change the base from acpi- to intel_ but it's just a theory.

I do not have an Intel CPU that uses this scheduler.

Hi,

Thanks for your useful tool.
I've upgraded from Ubuntu 12.04 to 16.04 and since then it's really slower. I suspect the cpu scaling does not kick in properly on heavy load.

I've tried increasing the max with your command-line tool but did not get any succes:

$ sudo pstate-frequency -S -m 100
pstate-frequency version 3.3.3
    pstate::CPU_DRIVER   -> intel_pstate
    pstate::CPU_GOVERNOR -> performance
    pstate::TURBO        -> 0 [ON]
    pstate::CPU_MIN      -> 24% [800000KHz]
    pstate::CPU_MAX      -> 40% [1320000KHz]

(Actually it did work once but after stopped working and the cpu_max did go back to 40% on its own)

I've tried various combinations, and your tool does have some ffect, but any cpu_max above like 40% or 60% gets ignored.
It is like there's some process that constantly overrides value set in /sys/devices/system/cpu/intel_pstate/max_perf_pct

Any idea on what could happen?
I have killed thermald and acpi_thermal_pm but it didn't have any effect
Note that it's hot in Paris today and my CPU is around 85°. Can it be a cause of that unability to apply the max.

For more background: link

This will allow --get to expand functionality to print out either the user's currently set CPU values, or the actual CPU frequencies running which will be retrieved by grepping the /proc/cpuinfo.

As of version 1.1.15, a memory leak has been noticed. After careful testing, I have come to the assumption that the leak is not directly associated with pstate-frequency.

A small test was conducted in which a Hello World program was built using g++ 5.1, and then checked with the valgrind-3.10 program. A memory leak of 72,704 bytes in 1 block was found. This same leak exists in pstate-frequency when run against valgrind. I have made the assumption that the leak is either in g++ or valgrind itself, and therefore will not be attempting to bisect and find a memory leak as I assume one does not technically exist.

pstate-frequency in powersaving mode (via "pstate-frequency -S -p auto" in my script triggered by a udev rule) perfectly sets my CPU to 800 MHz. However, upon resuming from suspend the CPU ramps up to 2.0 GHz, which rapidly depletes battery life, and running the aforementioned pstate-frequency command does not revert the computer to the original, pre-suspend state. All my other powersaving measures post suspend do function normally, so it does not appear to be a problem with the udev rule. (The pstate-frequency command should work from the cli were that the case.)

Prior to suspend, on battery power:
% cpupower frequency-info
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 3.30 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 800 MHz and 825 MHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 800 MHz.
boost state support:
Supported: yes
Active: yes

% pstate-frequency -G r
pstate-frequency 1.2.2[g++]
pstate::CPU_DRIVER -> intel_pstate
pstate::CPU_GOVERNOR -> powersave
pstate::NO_TURBO -> 1 : OFF
pstate::CPU_MIN -> 24% : 800000KHz
pstate::CPU_MAX -> 25% : 825000KHz

After suspend, on battery power:
% cpupower frequency-info
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 3.30 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 800 MHz and 825 MHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.00 GHz (asserted by call to hardware).
boost state support:
Supported: yes
Active: yes

% pstate-frequency -G r
pstate-frequency 1.2.2[g++]
pstate::CPU_DRIVER -> intel_pstate
pstate::CPU_GOVERNOR -> powersave
pstate::NO_TURBO -> 1 : OFF
pstate::CPU_MIN -> 24% : 800000KHz
pstate::CPU_MAX -> 25% : 825000KH

If there is anything else useful I may provide, please let me know. I am using a Fujjitsu T904 running on the Haswell Core i7 Processor, in ArchLinux 64-bit. Latest kernel 4.0.4-2.

Once the project has reached some interest, perhaps think about adding an entry to the ArchWiki

https://wiki.archlinux.org/index.php/CPU_frequency_scaling

Sounds like pstate_active basically doesn't care about anything set in sysfs at all. The processor drives entirely, including max_freq, min_freq, and turbo boost. If this is the case, we basically cannot support pstate_active at all (and I guess you wouldn't need anything for pstate_active since the CPU controls itself)

When using quicker hard drives like an SSD to boot, the quickened boot currently causes the pstate-frequency.service to fail, stating that it could not find a valid online power supply status. This is caused in part, because the machine boots very quickly (sub 1 second in userspace), causing the pstate-frequency.service file to fire perhaps before the required sys directories are created/mounted.

For the time being, enabling the udev service can apply the same effect of running the auto plan at boot. While not a huge issue, it will cause the service to fail making systemd mark the boot as not all clean.

Investigate systemd targets to see if pstate-frequency can be called only when sys is available.

On some computers (like my own laptop) enabling the no_turbo flags in the pstate files doesn't actually turn off turbo boost because the CPU reports its max frequency as the turbo frequency to the OS. Add support for the msr_tools package so that wrmsr and rdmsr can be used to toggle the actual Turbo Boost bit in the CPU architecture.

Add support for an input to the --get option which will return the output given from the command

grep MHz /proc/cpuinfo

Pipe will be faster and will not leave around a temp file, which can pose a security risk if a user with privileges was able to edit the line and drop in arbitrary code for execution.

Hi there ,

I use Ubuntu 22 server on a VMware VPS and I get "ERROR: pstate-frequency is not supported on your system" while running pstate-frequency command . what does that mean ? Why aren't I able to use it ?

The default configuration of the service/udevd makes it so by default it uses
00-auto.plan which in term uses 01-powersave.plan. The problem is this plan sets PLAN_CPU_MAX=0 on many cases resulting on max Mhz being = to the min Mhz.
I dont believe this is the desired configuration for anyone as in most systems it will make the laptop unresponsive.

Support for io schedulers will no longer be supported. Remove options relating to them for next update.

Hi,

the script throws an error message on a current RHEL7:

Error message

# ./pstate-frequency -G -c
cat: /sys/devices/system/cpu/cpufreq/boost: No such file or directory
./pstate-frequency: line 1090: [: : integer expression expected
pstate-frequency version 3.7.2
    pstate::CPU_DRIVER   -> pcc-cpufreq
    pstate::CPU_GOVERNOR -> performance
    pstate::TURBO        ->  [OFF]
    pstate::CPU_MIN      -> 36% [1200000KHz]
    pstate::CPU_MAX      -> 100% [3300000KHz]

Used kernel

# uname -a
Linux mysrv 3.10.0-514.6.1.el7.x86_64 #1 SMP Sat Dec 10 11:15:38 EST 2016 x86_64 x86_64 x86_64 GNU/Linux

Content of /sys/devices/system/cpu

# ll /sys/devices/system/cpu
total 0
drwxr-xr-x 8 root root    0 Feb 28 14:07 cpu0
drwxr-xr-x 8 root root    0 Feb 28 14:07 cpu1
[...]
drwxr-xr-x 8 root root    0 Feb 28 14:07 cpu8
drwxr-xr-x 8 root root    0 Feb 28 14:07 cpu9
drwxr-xr-x 2 root root    0 Feb 28 14:08 cpuidle
-r--r--r-- 1 root root 4096 Feb 28 14:07 isolated
-r--r--r-- 1 root root 4096 Feb 28 14:08 kernel_max
drwxr-xr-x 2 root root    0 Feb 28 14:08 microcode
-r--r--r-- 1 root root 4096 Feb 28 14:08 modalias
-r--r--r-- 1 root root 4096 Feb 28 14:07 nohz_full
-r--r--r-- 1 root root 4096 Feb 28 14:08 offline
-r--r--r-- 1 root root 4096 Feb 28 14:07 online
-r--r--r-- 1 root root 4096 Feb 28 14:08 possible
drwxr-xr-x 2 root root    0 Feb 28 14:08 power
-r--r--r-- 1 root root 4096 Feb 28 14:08 present
-rw-r--r-- 1 root root 4096 Feb 28 14:07 uevent

It would be really great if you could fix this error.

BTW: What do you think about adding the GitHub URL to the script header?

Regards,
Carsten

Add support for autocompletion under ZSH.

If statements everywhere, calls to string streams, the whole shebang. Right now I put that in place because it would prevent unneccessary allocations and still serve as a way to implement a global logger without resorting to a variable that is passed between almost every function, as that could arguably be uglier.

Still its not good.
As of commit: d734213

Recently I have some problems:

[root@archlinux audiolinux]# pstate-frequency --set --plan performance
ERROR: No power plan configuration found for argument: performance
ERROR: Not setting any CPU options

This for all plans.

Hello,
I updated pstate-frequency to the last version 3.7.0; now when I manually change the policy, for example with the command

sudo /path/pstate-frequency -S -g powersave -t off

I receive the following error:

/path/pstate-frequency: 1303: /path/pstate-frequency: cannot create /sys/devices/system/cpu/cpufreq/boost: Permission denied

I looked into that folder, and there is no 'boost' directory, nor I can create it even with sudo.

I am on Ubuntu 16.04, with an Haswell processor and the intel_pstate governor. I did not install service units, nor udev rules, I just run pstate-frequency manually because to change settings on the fly, the automatic switch w.r.t. battery state is done by TLP.

Regards,

Diego