[SOLVED] Suggestion: use "performance" CPU frequency governor
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
As I understand it, your relative's CPU is "a bit unstable" and has "poor cooling". Setting the governor on performance should not be persistent after a reboot, I can't follow your situation there.
How did you set it ondemand? Have you blacklisted the intel_pstate driver providing the kernel boot parameter intel_pstate=disable ?
After trying out the new rc.cpufreq on the machine in question and after experiencing instability I looked at what the cores were doing. I noticed at least one core was running hard all the time (I let it run for 5-10 minutes and checked the sensors temperatures occasionally) with just Plasma 5, xterm and Firefox open. cpufreq-info said one core at least was 4 GHZ and sensors said its temperature was 66 C. I then edited rc.cpufreq and put ondemand where performance was in the SCALING_GOVERNOR under the intel_pstate related if statement. Then rebooted and haven't had problems since.
I think instead of messing with governor speeds it would be a better option to up the min frequencies on intel processors with something like (max+min)/2. For my relatives needs they don't need "performance" at all. The instability is with the computer itself. My concern with "performance" is that one CPU core stayed at 4 GHZ and went to 66 C with fan cooling and the computer wasn't doing anything to warrant it.
Last edited by RadicalDreamer; 09-11-2018 at 12:09 PM.
In post 71, abga proposed changes to upsteam scripts (/etc/rc.d/rc.cpufreq and /etc/acpi/acpi_handler.sh) to handle two situations:
#1: "if the computer starts on batteries, then the CPU PM governor should be set on powersave"
#2: "after finishing the boot process and acpid is running, automatically switching the CPU PM governor based on running on AC Power connect/disconnect events."
For case #1, I think something in /etc/rc.d/rc.local is manageable. I could make a proposal in a later post.
Here, I would like to share my suggestion to manage case #2 without any change to /etc/acpi/acpi_handler.sh. This approach has the benefit of not forcing everybody to adopt the proposed changes.
I created a separate acpi event file and its associated handler script:
event file: /etc/acpi/events/ac_adapter_events
Code:
# Pass AC adapter events to one handler script
event=ac_adapter*
action=/etc/acpi/ac_adapter_handler.sh %e
handler file: /etc/acpi/ac_adapter_handler.sh
Code:
#!/bin/sh
# acpi handler for AC adapter events
IFS=${IFS}/
set $@
case "$2" in
AC*|AD*)
case "$4" in
00000000)
if [ -r /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ]; then
echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 1> /dev/null 2> /dev/null
logger "AC Power not available, setting CPU frequency scaling governor: $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor)"
fi
;;
00000001)
if [ -r /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ]; then
if grep -q "ondemand" /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors; then
echo "ondemand" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 1> /dev/null 2> /dev/null
else
echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 1> /dev/null 2> /dev/null
fi
logger "AC Power available, setting CPU frequency scaling governor: $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor)"
fi
;;
esac
;;
*) logger "ACPI action undefined: $2"
;;
esac
Then made /etc/acpi/ac_adapter_handler.sh executable and restarted acpid
After trying out the new rc.cpufreq on the machine in question and after experiencing instability I looked at what the cores were doing. I noticed at least one core was running hard all the time (I let it run for 5-10 minutes and checked the sensors temperatures occasionally) with just Plasma 5, xterm and Firefox open. cpufreq-info said one core at least was 4 GHZ and sensors said its temperature was 66 C. I then edited rc.cpufreq and put ondemand where performance was in the SCALING_GOVERNOR under the intel_pstate related if statement. Then rebooted and haven't had problems since.
I think instead of messing with governor speeds it would be a better option to up the min frequencies on intel processors with something like (max+min)/2. For my relatives needs they don't need "performance" at all. The instability is with the computer itself. My concern with "performance" is that one CPU core stayed at 4 GHZ and went to 66 C with fan cooling and the computer wasn't doing anything to warrant it.
First, just to clear some misunderstandings(again). If you're using a modern Intel CPU, starting with the Sandy Brdige architecture, the kernel will load the intel_pstate driver for the CPU PM. This driver does only support two governors, powersave (default) and performance. If you don't like the performance governor then your only other option is powersave, nothing else will be accepted by the intel_pstate driver. If you push the ondemand governor, like you did, the intel_pstate driver will ignore that and will use its default powersave governor instead.
Code:
# check what PM driver you're currently using
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
# check what governor is currently active
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
On your Skylake 6700K observations and issue, following the tests I ran, I can also confirm that with the governor set on performance, the CPU is keeping its core frequencies maxed out but had no problem with that, other than a slight increase in temperature. The temperature you reported (66 C) shouldn't be a concern and the reported frequency (4 GHz) is also not a problem (factory specs).
Don't know why are you experiencing the instability and would suggest:
- check your BIOS and disable any overclocking config (if any)
- make sure that the heatsink&fan combo is not applying too much pressure on the CPU https://www.pcgamer.com/intel-skylak...-some-coolers/
- get the latest BIOS / microcode for the CPU: https://en.wikipedia.org/wiki/Skylak...)#Known_issues https://www.pcworld.com/article/3021...ylake-bug.html
I'd still support the choice of setting the governor on performance for intel_pstate and considering your feedback useful but your issue an isolated case that might be the result of some other causes.
I have been lurking around too, this thread has been very informative.
Using TLP for more than 3 years now without noticing any adverse effects. Here are some defaults from its config file:
Code:
# Set CPU performance versus energy savings policy:
# performance, balance-performance, default, balance-power, power.
# Values are given in order of increasing power saving.
# Requires kernel module msr and x86_energy_perf_policy from linux-tools.
ENERGY_PERF_POLICY_ON_AC=performance
ENERGY_PERF_POLICY_ON_BAT=power
# Disk devices; separate multiple devices with spaces (default: sda).
# Devices can be specified by disk ID also (lookup with: tlp diskid).
DISK_DEVICES="sda sdb"
# Disk advanced power management level: 1..254, 255 (max saving, min, off).
# Levels 1..127 may spin down the disk; 255 allowable on most drives.
# Separate values for multiple disks with spaces. Use the special value 'keep'
# to keep the hardware default for the particular disk.
DISK_APM_LEVEL_ON_AC="254 254"
DISK_APM_LEVEL_ON_BAT="128 128"
# Hard disk spin down timeout:
# 0: spin down disabled
# 1..240: timeouts from 5s to 20min (in units of 5s)
# 241..251: timeouts from 30min to 5.5 hours (in units of 30min)
# See 'man hdparm' for details.
# Separate values for multiple disks with spaces. Use the special value 'keep'
# to keep the hardware default for the particular disk.
#DISK_SPINDOWN_TIMEOUT_ON_AC="0 0"
#DISK_SPINDOWN_TIMEOUT_ON_BAT="0 0"
# Select IO scheduler for the disk devices: cfq, deadline, noop (Default: cfq).
# Separate values for multiple disks with spaces. Use the special value 'keep'
# to keep the kernel default scheduler for the particular disk.
#DISK_IOSCHED="cfq cfq"
# AHCI link power management (ALPM) for disk devices:
# min_power, med_power_with_dipm(*), medium_power, max_performance.
# (*) Kernel >= 4.15 required, then recommended.
# Multiple values separated with spaces are tried sequentially until success.
SATA_LINKPWR_ON_AC="med_power_with_dipm max_performance"
SATA_LINKPWR_ON_BAT="med_power_with_dipm min_power"
With the default config laptop is responsive even on battery, with increase in battery life of around 1.5 hours.
YMMV.
P.S. powertop can be used to check power consumption and tunables.
abga proposed changes to upsteam scripts (/etc/rc.d/rc.cpufreq and /etc/acpi/acpi_handler.sh) to handle two situations:
#1: "if the computer starts on batteries, then the CPU PM governor should be set on powersave"
#2: "after finishing the boot process and acpid is running, automatically switching the CPU PM governor based on running on AC Power connect/disconnect events."
For case #1, I think something in /etc/rc.d/rc.local is manageable. I could make a proposal in a later post.
Actually I was only focusing on one goal, to set the governor on powersave if running on batteries and only change it to ondemand/performance if the AC adapter is connected. The 2 solutions for the 2 "situations" I described should be taken always together, as they're part of the same unique goal. I might have used some confusing wording and I apologize for that, not a native English speaker myself.
I made use of /etc/rc.d/rc.cpufreq for checking if the system was booted on batteries just for completing the goal and complementing acpid. acpid is not useful if there's no event happening and booting on batteries is an "event" that acpid, which is started later in the boot process, doesn't care about.
Your approach, isolating the ac_adapter* event and using a dedicated script for handling it, is interesting and as you said appropriate for users who might want to opt out. In your case, this needs to be documented, otherwise nobody will know about it.
I doubt that the changes I/you proposed will ever make their way upstream and I'm sorry now for not opening a new thread for this particular CPU PM improvement proposal. I was caught in the feedback "frenzy" and started to look for a solution, found one and documented it in post #71.
Last edited by abga; 09-11-2018 at 02:09 PM.
Reason: formatting
In post 71, abga proposed changes to upsteam scripts (/etc/rc.d/rc.cpufreq and /etc/acpi/acpi_handler.sh) to handle two situations:
#1: "if the computer starts on batteries, then the CPU PM governor should be set on powersave"
#2: "after finishing the boot process and acpid is running, automatically switching the CPU PM governor based on running on AC Power connect/disconnect events."
Regarding #1, I would suggest the opposite. Even if the computer boots on batteries, there could be spinning platters drawing power. I propose to boot the kernel as quickly as possible via "performance", then switch to "ondemand" or "powersave" once /sbin/init launches the /etc/rc.d scripts.
If there's a need to tune the HD power parameters (spin-down time, swap tuning, FS flushing), the adjustment(s) can be handled in rc.local. But by booting with "performance", the system launches rc.local sooner after boot.
Of course, this can be proven or invalidated by someone using a Kill-A-Watt. Any volunteers?
I'd still support the choice of setting the governor on performance for intel_pstate and considering your feedback useful but your issue an isolated case that might be the result of some other causes.
I thought ondemand was setting things to powersave but I wasn't sure. It acts like ondemand. I put 4K video on or a game and some processors jump 2 GHZ. I'm sorry that I made you explain that "again." Thanks for the links. I've been at a lost as to why the system all of sudden decided to hate Windows after 2 years. I've ran stress tests until the processor got real hot. The system is stable in Safe Mode in Windows 7.
I disagree with having a core running on max all the time. I wish there was a setting between powersave and performance like in Windows. One called "Balanced."
if anyone thinks that a system is/feels snappier when surfing the web, using office, compiling packages, I would say: welcome to the world of imaginations and placebos
we still have no use case where this makes a measurable difference, and where an average user has some benefit.
therefore heating CPUs, == more power consumption, and higher noise through fans.
Win for the user: microsecond on synthetic benchmarks, so nothing at all. A bad deal. except you want to heat your home this way.
Adding this change to Slackware was a failure, it just makes the time to a useful system longer because now there is one more additional fix to remember and to do.
I thought ondemand was setting things to powersave but I wasn't sure. It acts like ondemand. I put 4K video on or a game and some processors jump 2 GHZ. I'm sorry that I made you explain that "again." Thanks for the links. I've been at a lost as to why the system all of sudden decided to hate Windows after 2 years. I've ran stress tests until the processor got real hot. The system is stable in Safe Mode in Windows 7.
I disagree with having a core running on max all the time. I wish there was a setting between powersave and performance like in Windows. One called "Balanced."
You don't need to be sorry, the improper use of the ondemand governor for Intel based systems that are using the intel_pstate driver is the subject of this thread and it was described in every second/third post.
The powersave governor is also acting well once you start some (continuous) processes and the CPU is awake, that was never an issue, the issue (lagginess) starts to be evident when you do some tasks sporadically, that's browsing through the DE menus, browsing the internet, issuing some commands in the console, etc. And this might be more evident on low/medium-end CPUs and not on your high-end 6700K.
I said already that I don't understand what's wrong with your system and provided you with some hints. Setting the governor on performance should not cause any trouble after your restart your computer because this is a driver and its settings should not remain persistent.
You can always set your governor on powersave if you don't like keeping one core at its max frequency. This is a limitation of the intel_pstate driver, Intel should fix this, and again, the very subject of this thread.
if anyone thinks that a system is/feels snappier when surfing the web, using office, compiling packages, I would say: welcome to the world of imaginations and placebos
we still have no use case where this makes a measurable difference, and where an average user has some benefit.
therefore heating CPUs, == more power consumption, and higher noise through fans.
Win for the user: microsecond on synthetic benchmarks, so nothing at all. A bad deal. except you want to heat your home this way.
Adding this change to Slackware was a failure, it just makes the time to a useful system longer because now there is one more additional fix to remember and to do.
You don't need to be sorry, the improper use of the ondemand governor for Intel based systems that are using the intel_pstate driver is the subject of this thread and it was described in every second/third post.
The powersave governor is also acting well once you start some (continuous) processes and the CPU is awake, that was never an issue, the issue (lagginess) starts to be evident when you do some tasks sporadically, that's browsing through the DE menus, browsing the internet, issuing some commands in the console, etc. And this might be more evident on low/medium-end CPUs and not on your high-end 6700K.
I said already that I don't understand what's wrong with your system and provided you with some hints. Setting the governor on performance should not cause any trouble after your restart your computer because this is a driver and its settings should not remain persistent.
You can always set your governor on powersave if you don't like keeping one core at its max frequency. This is a limitation of the intel_pstate driver, Intel should fix this, and again, the very subject of this thread.
It caused problems with the computer in question after I restarted the computer twice but that computer has serious problems anyway. Performance setting triggered it. So Slackware should cater to low/medium-end CPUs with adequate cooling? I think upping the min freq would make more sense for these older computers. That is what I'll do when the time comes:
Quote:
Change min_perf_pct and max_perf_pct.
As root: echo XX > /sys/devices/system/cpu/intel_pstate/min_perf_pct (and max_perf_pct obviously)
XX being the percentage to which the frequency goes up to, relative to maximum frequency.
This makes sense because what min_perf_pct does is multiply the max frequency with the percentage selected. My max is 3.9 GHZ. min_perf_pct is set to 41 so my min freq is 1.6 GHZ which it is. I set it to 50 and my min freq for all cores is now 2.00 GHZ.
I guess each to their own but I don't think a core should be going full blast all the time. There has to be a better way to do this. I don't think Slackware should be shipping with this but it is our BDFL's decision. If the min frequencies isn't good enough then up it by a percentage is my answer to the performance problem. At least I figured out my solution to keeping my aging hardware relevant. https://www.kernel.org/doc/html/v4.1...el_pstate.html
Probably he wants to says that that Intel CPUs works happily with "ondemand" governor under 4.18.x and later, then this entire thread is a dead horse racing.
Last edited by Darth Vader; 09-12-2018 at 02:29 PM.
Probably he wants to says that that Intel CPUs works happily with "ondemand" governor under 4.18.x and later, then this entire thread is a dead horse racing.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.