[SOLVED] Suggestion: use "performance" CPU frequency governor

RadicalDreamer · 09-11-2018, 12:07 PM

Quote:

Originally Posted by abga

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.

gegechris99 · 09-11-2018, 12:45 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.

Reference:
https://wiki.archlinux.org/index.php..._configuration

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

Code:

chmod +x /etc/acpi/ac_adapter_handler.sh
/etc/rc.d/rc.acpid restart

This approach works on my Slackware64 14.2

Credit goes to abga for stoking my interest in this topic. Thanks.

abga · 09-11-2018, 01:26 PM

Quote:

Originally Posted by RadicalDreamer

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.

SCerovec · 09-11-2018, 01:51 PM

Quote:

Originally Posted by aaditya

Thank you for your kind words, kjhambrick :-)

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.

Edit-
https://linrunner.de/en/tlp/docs/tlp-faq.html

Code:

bash-4.3# /etc/rc.d/rc.tlp status
--- TLP 1.1 --------------------------------------------

+++ System Info
System         = FUJITSU 10601409549 LIFEBOOK T901
BIOS           = Version 1.15
Kernel         = 4.18.6 #1 SMP Wed Sep 5 07:29:56 UTC 2018 x86_64
/proc/cmdline  = \\boot\vmlinuz-generic-4.18.6 root=/dev/sda2 vt.default_utf8=1 vga=normal ro 4 spec_store_bypass_disable=on ro initrd=boot\initrd-4.18.6.gz
Init system    = sysvinit
Boot mode      = UEFI

+++ TLP Status
State          = enabled
Last run       = 08:44:20 PM,     35 sec(s) ago
Mode           = battery
Power source   = battery

bash-4.3#

since the first days of using it - looking good

abga · 09-11-2018, 02:05 PM

Quote:

Originally Posted by gegechris99

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.

gus3 · 09-11-2018, 08:18 PM

Quote:

Originally Posted by gegechris99

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?

RadicalDreamer · 09-12-2018, 05:37 AM

Quote:

Originally Posted by abga

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."

a4z · 09-12-2018, 05:46 AM

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.

abga · 09-12-2018, 09:18 AM

Quote:

Originally Posted by RadicalDreamer

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.

abga · 09-12-2018, 11:12 AM

Quote:

Originally Posted by a4z

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.

Personally, I'm sure about experiencing the ramp-up lagginess, confirmed observations on 3 different systems (laptops) and you can also take a look over this imaginative and placebo biased graph:
https://www.phoronix.com/scan.php?pa...linux315&num=6
You can always choose your preferred governor:
https://www.linuxquestions.org/quest...ml#post5898048
And you can always take care about the CPU power consumption on your mobile device, pretty easy:
https://www.linuxquestions.org/quest...ml#post5901577

SCerovec · 09-12-2018, 02:08 PM

Using the 4.18.x for a week now (our unofficial build).

I'm amused how this does not apply to the 4.18.x as it does to the 4.4.x series Slackware 14.2 still supports.

Amusing dead horse racing

RadicalDreamer · 09-12-2018, 02:22 PM

Quote:

Originally Posted by abga

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.

https://www.phoronix.com/forums/foru...nux-3-15/page2

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

RadicalDreamer · 09-12-2018, 02:24 PM

Quote:

Originally Posted by SCerovec

Using the 4.18.x for a week now (our unofficial build).

I'm amused how this does not apply to the 4.18.x as it does to the 4.4.x series Slackware 14.2 still supports.

Amusing dead horse racing

What do you mean?

Darth Vader · 09-12-2018, 02:27 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.

RadicalDreamer · 09-12-2018, 02:32 PM

Quote:

Originally Posted by Darth Vader

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.

I was thinking that too but I want confirmation!