I want to change the intel_pstate manager to ondemand, permanently. Now there is schedutil and it keeps the CPU clocking between max and turbo all the time.
I issue the command:
sudo cpupower frequency-set -g ondemand
And it’s ok, but reboot on schedutil again.
There are a lot of threads in different forums what to do but nothing works.
I’m not very proficient in Linux, I don’t understand what I should do.
The system works very nicely but the default settings make CPU running on too high speed.
Can you tell me what to install or change?
Below are some commands that I found, maybe they will tell you something, something is probably missing.
cpupower frequency-info
analyzing CPU 0:
driver: intel_cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 20.0 us
hardware limits: 800 MHz - 2.70 GHz
available cpufreq governors: ondemand performance schedutil
current policy: frequency should be within 800 MHz and 2.70 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 1.31 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
sudo cat / etc / default / cpupower
cat: / etc / default / cpupower: There is no such file or directory
sudo systemctl status cpupower
Unit cpupower.service could not be found.
sudo systemctl enable cpupower.service
Failed to enable unit: Unit file cpupower.service does not exist.
According to the command, I have intel_cpufreq and not intel_pstate. It is the same?.
What I put on is probably a little chaotic, it’s because I don’t understand these CPU settings.
But… is it really a problem? I mean, does it overheat or drain the battery too much?
With intel_pstate the frequency remains “high” even if the core is sleeping, so the real power consumption might be much less than you think.
For instance here with Leap 15.1 the “powersave” governor is active, but the frequency is always reported near max values:
LT_B:~ # 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: Cannot determine or is not supported.
hardware limits: 800 MHz - 3.60 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 3.60 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 3.42 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
LT_B:~ #
but when the system is close to idle cores are active (in C0 state) a small % of the time…
Perhaps a read here first to clarify why it’s changed to schedutil?
Yes, you’re right, I didn’t look at the link yet but I started to think about my arguments.
If schedutil is selected, it means that it’s better and should be used.
I’m not wiser then developers so I’m keen to keep the default governor.
But… is it really a problem? I mean, does it overheat or drain the battery too much?
That’s a good question:)
As a matter of fact, no, my laptop is really cold (35 - 55 C), it works silently.
the only thing is that when I see so high speed, I think that is not good for CPU for long-term use but this is my point of view.
I’m not a pro so It’s very probable that I have a wrong assumption.
If high speed is really not a problem, I’m very happy:)
However, I found one thread regarding constant high speed on Leap and it looks like it can be something wrong with some Open Suse patch:
High frequency might be a problem when sustained for several minutes on several cores at the same time.
Apparently on recent processors current governors and schedulers run a core at high frequency for a short time, then send that core to sleep if the average load is low, then switch to a different core to distribute the average load evenly.
And the p_state driver doesn’t scale back frequency before sending a core to sleep, so that that core still reports a high frequency even if it is actually almost powered off.
So you might have a problem if you see high frequency and a large % spent in C0 state (assuming that you have a Sandy Bridge or similar processor), which is not your case at the moment apparently.
However, I found one thread regarding constant high speed on Leap and it looks like it can be something wrong with some Open Suse patch:
Based on a quick skim of several articles including Malcolm’s references at kernel.org,
schedutil appears to be a very, very recent new governor introduced within the past year or so. Unlike other governors, it appears to be an attempt for the frequency changes to be adjusted more granularly and in response to workload. But, according to the Arch Wiki article on this topic, there are warnings that schedutil may not work well on older processors and BIOS
The above article doesn’t specify which processors and BIOS are affected and maybe that’s not easy to identify so soon after schedutil has been introduced so benchmarking and testing may be the only way to determine if today’s default use of schedutil is appropriate for your hardware.
Some other tidbits that came up…
CPU frequency management doesn’t need to use Userspace cpupower utilities but the ArchWiki article strongly suggests setting them up. Don’t know if it’s simply a philosophical difference between Arch and SUSE/openSUSE or a more concrete reason exists. That’s probably why you won’t find a cpupower.service and configurations in /etc/ on an openSUSE machine. These Userspace utilities may not exist for any other reason than to provide User access to modifying, but maybe on older hardware that’s important.
Your question about cpufreq and pstate is answered in Malcolm’s references… cpufreq can be considered a sub-category of pstate so pstate tools actually provide you with access to a greater number of parameters.
Both the references at kernel.org and the ArchWiki provide some suggested ways of benching your hardware, you can try them to try to identify any possible issues running schedutil, and if there is any improvement running the “ondemand” governor.
Hi
Testing the governor can be done with the cpupower-bench package…
This benchmark helps to test the condition of a given kernel cpufreq
governor (e.g. ondemand, userspace, conservative) and the cpufreq HW driver
(e.g. powernow-k8, acpi-cpufreq, ...).
For that purpose, it compares the performance governor to a configured
powersave module.
The references provided by Malcolm are exhaustive but somewhat convoluted.
To test the current state of affairs I booted up a Gnome Live Tumbleweed and found myself in a situation similar to the OP, namely intel_cpufreq and schedutils governor are active by default on an Haswell processor.
In a nutshell, intel_cpufreq is reported when the intel_pstate driver works in the passive mode, which looks as the new default (since kernel 5.8 or 5.9?).
And the schedutils governor looks like the new default since kernel 5.9.
To return to the setup I was used to, I have to boot with the “intel_pstate=active” boot option, so that I see “powersave” as default governor and “performance” as an option.
I did no comparative test yet, the only visible effect so far is that cpupower seems to report somewhat lower frequencies for comparable loads with the new default, so I would not change that default until I know what I am doing (and why).
