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

bassmadrigal · 08-30-2018, 08:51 AM

Quote:

Originally Posted by abga

I haven't seen the new rc.cpufreq (part of the a/sysvinit-scripts-2.1-noarch-18.txz) but if it's looking in /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors and picks ondemand if it's available and performance if it's not, then you'll be good with your AMD, ARM users will be fine and other older Intel CPUs (pre Sandy Bridge) users will be happy too. AFAIK it's starting with Intel's Sandy Bridge where intel_pstate is activated.

Here's the relevant code snippet:

Code:

# For CPUs using intel_pstate, always use the performance governor. This also
# provides power savings on Intel processors while avoiding the ramp-up lag
# present when using the powersave governor (which is the default if ondemand
# is requested on these machines):
if [ "$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver)" = "intel_pstate" ]; then
  SCALING_GOVERNOR="performance"
fi

So it will only apply to systems using intel_pstate as their scaling driver.

http://bear.alienbase.nl/cgit/curren...pts/rc.cpufreq

brianL · 08-30-2018, 10:44 AM

Using that rc.cpufreq from current works OK in 14.2. This refurbished T3600 is the only thing I've got that isn't pre-Sandybridge. Seems quieter using performance, unless it's my imagination (wasn't noisy before, anyway).

Code:

brian@slackdesk2:~$ uname -p
Intel(R) Xeon(R) CPU E5-1650 0 @ 3.20GHz
brian@slackdesk2:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
intel_pstate

EdGr · 08-30-2018, 11:06 AM

Quote:

AFAIK it's starting with Intel's Sandy Bridge where intel_pstate is activated.

You are right. I re-checked my Nehalem machine and it is using acpi-cpufreq.

Quote:

if you have use cases where tens to hundreds of milliseconds matter, what is not a every day every user scenario, than this might be a better candidate for special settings, imho

My experience differs. The delay affected interactive work, especially on my Haswell-E desktop with a 4K monitor.

My everyday use case is writing and testing software.

Ed

upnort · 08-30-2018, 12:11 PM

Regarding the questions raised about my suggestions with the new rc.cpufreq, how does a user force using powersave mode with an intel_pstate CPU -- without modifying rc.d scripts?

The new rc.cpufreq script presumes all users want to use the performance option.

I have been editing Slackware rc.d scripts for years. Doesn't bother me, but the approach is messy. Generally, not touching rc.d scripts is preferred. All rc.d scripts using parameters and variables should store that information in a sourced text file. A cleaner approach for administration.

Placing a respective conf file in /etc/rc.d is doable, but recently Pat started using /etc/default (atd, crond, etc.). While I am not advocating Slackware become any kind of clone, using /etc/default is consistent with other distro practices. That said, I don't really care if a cpufreq.conf file appeared in /etc/rc.d.

Parameters and variables used in rc.d scripts really should be in sourced text files.

volkerdi · 08-30-2018, 12:18 PM

Quote:

Originally Posted by upnort

Regarding the questions raised about my suggestions with the new rc.cpufreq, how does a user force using powersave mode with an intel_pstate CPU -- without modifying rc.d scripts?

Call rc.cpufreq with the desired parameter from rc.local.

upnort · 08-30-2018, 12:24 PM

Quote:

Call rc.cpufreq with the desired parameter from rc.local.

Yes, I mentioned that option in my first post about the new rc.cpufreq. Seems everybody but you missed that point. Hence in my last post I was being rhetorical.

abga · 08-30-2018, 01:55 PM

@bassmadrigal
Thanks for the link, I haven't had a search warrant for AlienBoB's stuff but only looked after the updated sysvinit-scripts-2.1-noarch-18.txz on some mirrors without success.

@volkerdi
Maybe you want to consider my suggestion, leave SCALING_GOVERNOR= empty/user defined, extend the conditional statement and keep it all in one file, as it was before:

Code:

 
#If you want to manually choose a governor, pick one from above and provide it to the next line
SCALING_GOVERNOR=
# For CPUs using intel_pstate, always use the performance governor. This also
# provides power savings on Intel processors while avoiding the ramp-up lag
# present when using the powersave governor (which is the default if ondemand
# is requested on these machines):
if [ -z "$SCALING_GOVERNOR" ]; then
 if [ "$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver)" = "intel_pstate" ]; then
   SCALING_GOVERNOR="performance"
 else
   #Set the default governor as ondemand 
   SCALING_GOVERNOR="ondemand"
 fi
fi
# If rc.cpufreq is given an option, use it for the CPU scaling governor instead:
if [ ! -z "$1" -a "$1" != "start" ]; then
  SCALING_GOVERNOR=$1
fi

Generally speaking, not sure which one is more reliable:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
or
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
Certainly, checking the first one is easier

abga · 08-30-2018, 02:03 PM

#off topic
Wow! Thanks bassmadrigal, now I have two pairs of balls (reputation), soon I'll become a guru

abga · 08-30-2018, 03:56 PM

Quote:

Originally Posted by a4z

which is, when you are on a notebook and travelling, irrelevant.
like for most all other common user tasks
so I hope the change did not effect notebook installations?
I even have doubts that it makes sense on most of workstations also
if you have use cases where tens to hundreds of milliseconds matter, what is not a every day every user scenario, than this might be a better candidate for special settings, imho

Sorry to interfere, but I believe that your first goal in using a computer is to do work on it and expect it to perform well. I noticed the laggines with the intel_pstate set on powersave some years ago when I bought my first Haswell Core i3 (dual core), did some investigation / wrote some notes, put the governor on performance and forgot to report it, actually I'm pretty new here on LQ and never considered it to be a Slackware issue but something Intel / kernel devs should care about. I can also confirm that this laggines is apparent with simple tasks that are executed in a console and the system is way more "snappier" if the performance governor is chosen.
Regarding mobile computers, I do believe that you need to get some special attention for them anyway, do some system tuning and setting the CPU frequency governor on powersave should be one of them.
After all, this powersave governor for intel_pstate should be the equivalent for the ondemand governor that comes with acpi-cpufreq, but it's not and ATM this workaround, setting the governor on performance for intel_pstate, looks to be the right choice.

abga · 09-03-2018, 08:32 AM

I was about to do some comparative ramp-up speed related tests between the intel_pstate driver with the governor set on powersave and acpi-cpufreq with the governor set on ondemand. Didn't know how to approach it without spending a week on coding some test routines and dropped it. Sorry.

I've noticed that some improvements have been recently made to the intel_pstate driver, reporting substantial performance increase under the powersave governor:
http://lkml.iu.edu/hypermail/linux/k...5.2/00014.html
Kernel commits:
https://github.com/torvalds/linux/co...intel_pstate.c

This particular commit hasn't made its way into the 4.4.153 kernel, neither into 4.14.67 but only into 4.18.5:
https://github.com/torvalds/linux/co...e3654d87258879

The intel_pstate.c from 4.14.67 has some more updates compared to the one from 4.4.153

intel_pstate driver interesting documentation:
https://www.kernel.org/doc/html/v4.1...el_pstate.html

EdGr · 09-03-2018, 10:32 AM

Interesting.

I am not surprised that the powersave governor is currently being tweaked. The trade-off between performance and power/energy is always subject to improvement.

The powersave policy is intended for laptops running on battery power. It can also reduce TCO in a data center full of servers.

In contrast, a desktop PC user will almost always favor performance over power.

There is a step up from the "performance" policy - overclocking.

I have built two high-end desktop PCs. These machines have vastly over-provisioned power supplies and cooling. Pushing the hardware to its failure point and backing off slightly is for the lunatic fringe, IMO. These people must not keep any important data on their computers.

I like performance at the manufacturer-specified frequency and voltage.
Ed

abga · 09-03-2018, 12:30 PM

Intel put some effort in enhancing the PM for their latest CPUs (last 7 years or so) with all these P-states and C-state & etc. Not a bad development after all, but I guess they were mainly pushed by the industry to do so. Comatose level of PM was required:
https://www.computerworld.com/articl...e-zombies.html

Some years ago, before I switched to Haswell I was working on a Core2 Duo (Merom) on which the CPU PM settings was acpi-cpufreq -> ondemand. That Core2 Duo had simple P-states for the "Enhanced Intel SpeedStep Technology", which translates to active frequency change based on load and AFAIK no low power idle states C-states. Switching to Haswell was my first experience with intel_pstate, found out that the rc.cpufreq is not handling the governor properly (setting the nonexistent ondemand for intel_pstate), experienced the laggines with powersave and turned it on performance (did it on all other new systems ever since).
As mentioned before, my only problem with the performance governor is that the fans are not stopping while performing normal "office" tasks and because of this I always considered to switch back to acpi-cpufreq -> ondemand, at least just for testing. Wasn't sure if that would be a good move, fearing compatibility issues.

But now, in the intel_pstate driver documentation (last link from my previous post) I found some interesting sections:

1. Confirming that intel_pstate -> powersave is (roughly) the equivalent of the acpi-cpufreq -> ondemand
Section Active Mode:
"For example, the powersave P-state selection algorithm provided by intel_pstate is not a counterpart of the generic powersave governor (roughly, it corresponds to the schedutil and ondemand governors)."

2. It also confirms that acpi-cpufreq is able to make use of the ACPI tables (limited P-states set) provided by the platform firmware.
Section: intel_pstate vs acpi-cpufreq
"The information returned by the ACPI _PSS objects is used by the acpi-cpufreq scaling driver. On systems supported by intel_pstate the acpi-cpufreq driver uses the same hardware CPU performance scaling interface, but the set of P-states it can use is limited by the _PSS output."

With these new infos/confirmations and since I don't need the "deep sleep" P-states/C-states to keep my systems in comatose, I'll disable intel_pstate, use acpi-cpufreq -> ondemand instead and check how the system will perform - lagginess / fans stop spinning. Will report back after some days.

abga · 09-07-2018, 11:22 AM

By looking for a solution to provide me good system responsiveness (snappiness) without keeping the CPU fan always spinning, like it does with intel_pstate set on performance, I disabled the intel_pstate driver and used the acpi-cpufreq set on ondemand instead.
Added the boot parameter in lilo.conf: append = "intel_pstate=disable"
So far, compared to intel_pstate-performance I can state that the responsiveness with acpi-cpufreq->ondemand is the same, the latter is changing the CPU frequency dynamically and is keeping the CPU cool, under 54C, on an average load of 20% (KDE4+Firefox+LibreOffice started but idle). The CPU fan is only starting every now and then when the temperature is getting above 53-54C.
I tested this on 2 systems (laptops), Haswell dual core i3 and Skylake dual core i7, both powered by Slackware 14.2 - kernel 4.4.153
Focused (observed) more on the Haswell i3 because it was the system I was mainly working on.

<EDIT>
Regarding Skylake and newer architectures, some improvements have been made with respect to PM and responsiveness.
The Speed Shift, which is known as HWP, Hardware P-States, is only supported with the 4.5.y kernels and its support is automatically enabled by intel_pstate:
https://www.kernel.org/doc/html/v4.1...el_pstate.html
"Active Mode With HWP
If the processor supports the HWP feature, it will be enabled during the processor initialization and cannot be disabled after that. It is possible to avoid enabling it by passing the intel_pstate=no_hwp argument to the kernel in the command line."
</EDIT>
https://www.anandtech.com/show/9751/...ive-processors
https://www.phoronix.com/scan.php?pa...4.5-SKL-PState

This HWP might improve the responsiveness for when intel_pstate is used with the powersave governor. Didn't test it, have no time/interest.
I believe that by using powersave, the intel_pstate driver puts the CPU in some lower C-states, literally cutting the power to some subsystems, thus the laggines / ramp-up delay.
https://www.thomas-krenn.com/en/wiki...s_and_C-states

Some details about the tests on Haswell core i3 (same behaviour on Skylake core i7):
- acpi-cpufreq set on ondemand. Good responsiveness, CPU Fan only spinning from time to time and the CPU frequency changing dynamically.

Code:

# output of:
watch -n 1 "sensors && grep \"cpu MHz\" /proc/cpuinfo"

Every 1.0s: sensors && grep "cpu MHz" /proc/cpuinfo
coretemp-isa-0000
Adapter: ISA adapter
Physical id 0:  +49.0°C  (high = +100.0°C, crit = +100.0°C)
Core 0:         +49.0°C  (high = +100.0°C, crit = +100.0°C)
Core 1:         +48.0°C  (high = +100.0°C, crit = +100.0°C)

dell_smm-virtual-0
Adapter: Virtual device
Processor Fan:    0 RPM
CPU:            +48.0°C
Ambient:        +53.0°C
Other:          +48.0°C
GPU:            +46.0°C

cpu MHz         : 1700.000
cpu MHz         : 1100.000

- intel_pstate set performance. Good responsiveness, CPU Fan constantly spinning and the CPU frequency always at maximum (except with 1699.933, whatever that means):

Code:

# output of:
watch -n 1 "sensors && grep \"cpu MHz\" /proc/cpuinfo"

Every 1.0s: sensors && grep "cpu MHz" /proc/cpuinfo
coretemp-isa-0000
Adapter: ISA adapter
Physical id 0:  +53.0°C  (high = +100.0°C, crit = +100.0°C)
Core 0:         +53.0°C  (high = +100.0°C, crit = +100.0°C)
Core 1:         +50.0°C  (high = +100.0°C, crit = +100.0°C)

dell_smm-virtual-0
Adapter: Virtual device
Processor Fan: 2387 RPM
CPU:            +52.0°C
Ambient:        +54.0°C
Other:          +52.0°C
GPU:            +49.0°C

cpu MHz         : 1699.933
cpu MHz         : 1700.000

Conclusion. I'm keeping acpi-cpufreq set on ondemand for my needs and disabling intel_pstate with the kernel boot parameter intel_pstate=disable.
Should you need something between intel_pstate->powersave and intel_pstate->performace, acpi-cpufreq->ondemand can fill the gap.

a4z · 09-07-2018, 12:55 PM

great report, thanks!
I thought on notebooks that was/is the default, querying if a battery is available, if, than ondemand,
on the wrong system currently to look on my 14.2 installation, but did this change?
The other thing is, as I already mentioned, for notebook users if in 15.0 the default will be performance, its not a good default
and I do not know how it behaves on workstations, I guess performance will also cook the heaters.

At work I know I have ondemand per derault, and when I run celero or google benchmark or testing with AFL I explicitly switch, but this is an other distro

abga · 09-07-2018, 01:30 PM

Thanks!
Not sure you followed this thread in detail, but the main issue is that starting with the (already old) Intel Sandy Bridge CPU architecture, the kernel is automatically setting the intel_pstate driver as default, which doesn't support the ondemand governor, but only powersave and performance. Without any provisioning it defaults on powersave, which is laggy and the only alternative is to set it on performance.
Or, like I suggested now, forcefully disable the intel_pstate driver with the kernel boot parameter intel_pstate=disable, unfortunately it's the only available way to do it, and then the kernel will use the older acpi-cpufreq driver which supports the ondemand governor.

This change, setting the governor on performance if the intel_pstate driver is used has only made its way into Slackware -current:
ftp://ftp.osuosl.org/pub/slackware/s.../ChangeLog.txt (Tue Aug 28 22:05:19 UTC 2018)

On Slackware 14.2 stable, the rc.cpufreq script is still defaulting on the ondemand governor, which is ignored by the intel_pstate driver (if it's loaded and active) and the default powersave is used. The only way to change that is to either modify /etc/rc.d/rc.cpufreq and set the SCALING_GOVERNOR=perfomance or call rc.cpufreq with the performance parameter from within /etc/rc.d/rc.local, like:

Code:

/etc/rc.d/rc.cpufreq performance

Or, as mentioned before, disable the intel_pstate driver with the kernel boot parameter intel_pstate=disable