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.

3 members found this post helpful.

They can edit /etc/default/cpufreq.

If only it would be that easy to just turn it off. On 4.4.y kernels you don't seem to have an option other than rebuilding the kernel without CONFIG_CPU_FREQ=y. On newer kernels, according to the docs - haven't tried it, you can pass the kernel boot parameter: cpufreq.off=1 (maybe together with cpuidle.off=1).
https://lore.kernel.org/patchwork/patch/764825/
But then disabling the OS support for the CPU PM will leave you without any control over it and the BIOS will take over and do whatever it was programmed to do, dynamic frequency scaling for sure, and you might not have too many options to change the BIOS settings.

I cannot follow your "Added bonus:" statement/joke, looked over some bug reports and the root causes were generally wrong memory timing/freq. multiplication&co and not the CPU PM drivers.

It looks like you have a strong interest in actually keeping the CPU PM enable on OS level and write your own "driver".
Indeed, go outside & play, you might succeed to hack yourself into the CPU HW PM and override the T-states
https://github.com/gus3/therm_guard
http://impact.asu.edu/cse591sp11/Nahelempm.pdf

1 members found this post helpful.

Does the updated rc.cpufreq consider /etc/default/cpufreq ?

Yes, it does. And this is the file /etc/default/cpufreq:

1 members found this post helpful.

Thanks for the update! I was again looking after updated packages on some mirrors instead of checking AlienBoB's stuff:
http://bear.alienbase.nl/cgit/curren...pts/rc.cpufreq

Make sure that you are happy with the performance you get if you disable intel_pstate.

When intel_pstate first came out, I noticed a big performance jump on my Sandy Bridge laptop. Intel_pstate is much more aggressive in boosting CPU frequency than acpi-cpufreq, especially when multiple cores are active. This made the Sandy Bridge laptop nearly as fast as the prior-generation Nehalem desktop (at least until the laptop reached its thermal limit).

The fan switching to high speed sooner is a consequence of the more aggressive frequency boost.
Ed

so is the new default performance, even on notebooks?
not sure that this was a well through thought decision, the far majority of all user cases does not need this default at all, also not on workstations, and making the non power user to play around with special configs rather than the power user that thinks s/he is so special, ....

Also checked now one more dist, also here
after this I would not be surprised if Slackware is the only distribution that will ship per default with the performance governor
and will get some review notes about to be the distro that makes your fans spinning, your batteries draining, and you CPU heating

Personally, I'm fine with the performance of acpi-cpufreq->ondemand on my Intel CPUs and I'm not noticing any difference compared to intel_pstate->performance, other than having the CPU fans stopped when the system is idle. It might be that the intel_pstate is more aggressive, but I can't find any reference to that, only believing you. The "aggressiveness" of intel_pstate->performance I observed was keeping the CPU frequency maxed out and my CPU fans constantly spinning, at their lowest speed I must admit. The responsiveness is the same and once I start hammering the CPU with some processes the performance is also the same.

Yes, but only with Slackware -current and you can always set the governor on whatever value you like, powersave for instance.

Yeah, man! Way to go!

Let's complicate the rookies life even more!

BTW, did you heard about a thing called "sane defaults" ?

Those "sane defaults" aren't about maximum performances for lazy Gurus, but well... about sane defaults, useful for everyone as starting point.