Suggestion: use "performance" CPU frequency governor
 

The default "ondemand" governor maps to "powersave" on modern Intel CPUs. The powersave governor takes several hundred milliseconds to ramp to maximum frequency.

To work around this, I have in my /etc/rc.d/rc.local:

The difference is measurable on benchmarks. Interactive response is snappier. The computers still idle efficiently.

Disclaimer - all of my computers are AC powered.
Ed

Maybe that is useful for the Intel users, but for those having AMD processors your suggestion will make the CPU to stay at max frequency and the CPU fan to go nuts.

Also, for those with laptops, the "performance" governor will be a disaster no matter which company produced their CPUs. ;)

So, how about yourself to tune your "/etc/rc.d/rc.cpufreq" and be happy with your micro-benchmarks? I talk about this well commented line:

Indeed, the intel_pstate driver only supports "powersave" (default) and "performance" and I can confirm what EdGr reported, the default "powersave" is just too lazy. This "powersave" should be the equivalent of the "ondemand" governor that works under the acpi-cpufreq driver for other non-Intel CPUs, but it's not. Like the OP suggested, I always set the governor on "performance" for Intel CPUs, even on laptops, without experiencing any thermal issues, the fan is indeed spinning a little and doesn't stop, but then I'm only using new (power efficient) CPUs, past Haswell.
Good lecture:
https://www.kernel.org/doc/html/v4.1...el_pstate.html
+
https://www.kernel.org/doc/Documenta...user-guide.txt
https://www.kernel.org/doc/Documenta.../governors.txt

I wrote some notes some time ago and considered disabling the intel_pstate driver and using the acpi-cpufreq instead, checking if its "ondemand" governor(algorithm) is better(faster) than the intel_pstate "powersave", but forgot about it. Thankful now about this thread, reminding me about it. Will need to go through these when I'll find some time available:
https://unix.stackexchange.com/quest...r-conservative
https://www.phoronix.com/scan.php?pa...linux315&num=1

Darth Vader - the comments in rc.cpufreq are obsolete for modern Intel CPUs.

abga - thanks for the links!

On my Intel Nehalem, Sandy Bridge, and Haswell-E CPUs, there are only two governors, "performance" and "powersave". "Powersave" makes the Haswell-E desktop sluggish. "Performance" cuts its power consumption in half when idle. I have measured both. :)

My Sandy Bridge laptop does not mind being run in performance mode on AC power. Unfortunately, the laptop no longer has a working battery.
Ed

ondemand works fine for me. If I am using something demanding it takes a few seconds for it to ramp up. I tried performance recently for Rise of the Tomb Raider because that was their recommendation. After the game ended the CPU frequency was still at about max on a few cores. I like how ondemand is ondemand. Plasma 5 running Firefox only requires ~1.60 Ghz on all cores so I don't need it to run at about 4 Ghz all the time.

When governor is set "ondemand", is there a way to follow dynamically the status change ? Or is it just to look at cpu activities ?

https://www.kernel.org/doc/Documenta...user-guide.txt

The current frequency of cpu 0 is at:

/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

You could, say, have Conky "cat" that every second.

with conky I use to show the cpu freq changes in real time.

Keep in mind the frequency adjustments are much more rapid than you can observe.

The way to measure the difference is to write a benchmark which goes from idle to full load and back to idle in less than one second.
Ed

to see it in a terminal in realtime you can also use

and EdGr, what you said is true but I think viewing the change every second or so give you the information you would need.

I did a before and after Slackware64 Current update. Here is ondemand and performance frequencies according to cpufreq-info. Plasma 5, one xterm open, and Firefox open with just this page with an i7 Ivy Bridge 3770. Performance has the CPU running ~2.20 GHz more.

One issue I came across with Rise of the Tomb Raider is that I couldn't set it back and forth from ondemand to performance on the command line. I tried /etc/rc.d/rc.cpufreq performance and it would change to performance but when I tried to set it back to ondemand the CPU still acted like it was on performance based on cpufreq-info and rc.cpufreq would report it as on performance. I was using these instructions under "More Performance Options": https://docs.slackware.com/studioware:tips_and_hints

I have this on my laptops:

Edit: Oh! And also this in /etc/rc.d/rc.local:

This thread can be marked as solved:Thanks EdGr and Pat.

Thank you all for your answers and explanations ! :)

Marking thread as solved. We just got faster computers. :)
Ed

New kernel! New cpufreq governor! Don't know if I can stand this pace of change at my age!!! ;)

Do I understand that if the default performance option is used that the CPU still conserves energy, despite always running close to top speed?

Spurred by this thread I now am testing the default performance option. According to conky and cpufreq-info, my CPU now is mostly running at max frequency. Fan speeds are tad higher now too.

Previously I was using the ondemand option, which triggered defaulting to the pstate powersave option.

Edit: What is meant by ramp-up lag? Are we talking micro or milliseconds or several seconds? BTW, I am using a Sky Lake quad core Intel i5-6400.

Decided to test the performance governor also. My Haswell-E now runs at max speed about 80% of the time, but does idle most cores when not in use. Temperatures went up a few degrees Celsius.

@upnort
There are definitely fractions of seconds and the exact delay is to be measured, if you know how, I don't, without causing myself to much load and influencing the results, maybe Intel knows better. The problem with this delay, or ramp-up lag, is that it's apparent especially in a resource hungry DE, KDE for instance, where you can clearly notice the sluggishness. Maybe not that apparent on some high end Core i7/i8...etc.
In my post #3 there's a link pointing to an older benchmark (phoronix) about the governors (algorithms) and on page 6 you can find a nice and conclusive time-graph where these are compared.
And then there could be other factors too, BIOS PM, the CPU's own PM (if any) and the quality of the intel_pstate driver.
The only more detailed info I could find about these CPU states is:
https://software.intel.com/en-us/art...ckage-c-states
- it covers the Xeon CPUs, but down on the page it states:
"We discussed the different types of power management states. Though the concepts are general, we concentrated on a specific platform, the Intel® Xeon Phi™ coprocessor. Most modern processors, be they Intel Corporation, AMD* or embedded, have such states with some variation."

@Daedra
These newer CPUs, starting with Haswell are very efficient and under normal usage they don't produce too much heat, thus the fan doesn't even start spinning with the powersave governor. Talking about laptops. Although I'm using the performance governor myself, I do have an issue with it, it's actually not optimal. The fans are spinning constantly at lower speed and these are mechanical components with somewhat limited lifetime that I might like to protect. That's why I'll try to blacklist the intel_pstate driver and observe how the old acpi-cpufreq with the governor "ondemand" is actually behaving. Now this is not recommended as the intel_pstate is chosen now by default for Intel CPUs in the Linux kernel, but still, it's worth trying. Hope I'll get some time during the weekend to play with it and do some benchmarks.

Modern CPUs have fine-grained gating on both the clock and power supply. When idle, large parts of the CPU core are shut off which makes the input clock frequency mostly irrelevant.

In principle, the powersave governor reduces power (and energy!) by not going to maximum frequency/voltage right away when a CPU core becomes busy. I measured the effects some time ago, and as I recall, the performance loss occurred over a timescale of tens to hundreds of milliseconds.
Ed

I use MATE. I never heard anybody call the DE resource hungry. :)

I guess the only way to know for sure is connect the kill-a-watt meter. :)

My notes from my original assembly:

79 watts max CPU frequency
54 watts with CPU idle

I just hope the new kernel setting does not screw up things for us AMD users.

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.

How about rc.cpufreq sourcing a user-defined /etc/default/cpufreq file?

A person might not want to use the performance option and prefers powersave.

As is, the new script requires 1) editing rc.cpufreq to comment out the new pstate test, 2) editing rc.M to change the start parameter, or 3) editing rc.local to relaunch rc.cpufreq with the desired powersave parameter.

Sourcing a user-defined file in /etc/default avoids editing the rc.d scripts.

Creating a new conf file for a simple value might be a little overkill IMHO.
I'm not sure I'm able to follow your logic, don't understand why 1) is necessary, what do you want to comment out? Establishing the best default governor depending on the system? It'll be a variable that might or might not be used in the next stage of the script, depending on how rc.cpufreq was called, with or without a parameter. Simple and elegant.
I also cannot follow why 3) is necessary, only step 2) is sufficient, that's:

Given that rc.cpufreq contains the necessary instructions to manually set the preferred governor, leaving SCALING_GOVERNOR= empty, using a different variable for choosing the appropriate governor from /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors and then expanding the conditional statement, checking first if the "override" SCALING_GOVERNOR is set by the user, using it to set the governor and breaking the loop, would be a better approach, keeping it all in one file.

I think the point is that the file in /etc/default would not be overwritten if the RC scripts get an update?

Not a big thing, but still...

KR
Mel

/etc/rc.d/rc.cpufreq.conf would be more Slackwarey.

Is there anything wrong with editing rc.cpufreq to read the desired governor?
to

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

Here's the relevant code snippet:

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

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

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

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

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

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. :)

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.

@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:
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 :)

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

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.

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

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

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.

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.
- intel_pstate set performance. Good responsiveness, CPU Fan constantly spinning and the CPU frequency always at maximum (except with 1699.933, whatever that means):
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.

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

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:
Or, as mentioned before, disable the intel_pstate driver with the kernel boot parameter intel_pstate=disable

Previously I proposed allowing users to define their preferences in /etc/default/cpufreq. The rc.cpufreq script should source that choice and when not found rollover to sane defaults.

Using /etc/default/cpufreq avoids editing and modifying rc.cpufreq.

In abga's edge case situation, a comment in /etc/default/cpufreq or rc.cpufreq would help users know when to use intel_pstate=disable when needed.

For myself I prefer powersave. The new rc.cpufreq overrides that preference. With the current design I have to run the rc.cpufreq script a second time in rc.local or modify rc.cpufreq.

And I proposed to allow the users to change the governor from within the rc.cpufreq, as it was before:
https://www.linuxquestions.org/quest...ml#post5900631

I'm with you on the comment, but then it's the kernel folks who decided that the intel_pstate is better suited for Intel CPUs (starting with Sandy Bridge) and automatically chosen in favor of acpi-cpufreq.

Thing is, there are many improvements to the intel_pstate that are not merged into the actual 4.4.y kernel that's coming with Slackware 14.2 but only in newer kernels (mentioned them in a previous post). These improvements, especially the HWP(Hardware P-States) support, might improve the way intel_pstate->powersave is behaving, although I don't believe it'll improve too much on older Intel CPUs, pre Skylake. This Slackware workaround, to put the intel_pstate by default on performance is still the best way to resolve the ramp-up lag issue IMO.

Both of these options are available with the latest rc.cpufreq from yesterday's updates. Also, I looked at abga's proposed changes and did not see any functional difference from what the latest script does.

You're right, the users, who always need to have some basic bash scripting knowledge, can edit the new conditional statement for the intel_pstate check and set the SCALING_GOVERNOR="powersave" from within rc.cpufreq file if the intel_pstate driver is used (not exactly how it was before).
Please carry on with the good work you're doing, I already said I'm not insisting on them, just replied to upnort.

The ultimate powersave CPU frequency governor: turn the d@mn thing off, go outside & play.

Added bonus: no segfaults or kernel panics with this frequency governor. :D :thumbsup: