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. |
Quote:
Quote:
|
Quote:
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: |
Quote:
|
Quote:
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 |
Quote:
|
Quote:
Code:
# To select a particular CPU governor option for /etc/rc.d/rc.cpufreq, |
Quote:
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 Code:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver and will get some review notes about to be the distro that makes your fans spinning, your batteries draining, and you CPU heating |
Quote:
|
Quote:
|
Quote:
Let's complicate the rookies life even more! :thumbsup: 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. |
All times are GMT -5. The time now is 10:57 PM. |