SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am trying to iron out the proverbial kinks in my office desktop with Slackware 15.0 64-bit. The system has a 4-core Skylake CPU.
I do not understand the new intel_pstate support. I have tried reading online documentation, but the result is a headache, glassy eyes, and a desire to kick cute kittens. I need a simple flowchart perspective how this new frequency scaling functions.
For years with 14.2 and the 4.4 kernel I always used the powersave option. I used Xfce. Everything functioned fine. The computer was not a foot warmer.
With 15.0 that option no longer works the same. The challenge is I have been whacking away at KDE 5 quite a bit and actually enjoy using KDE again. I want to keep KDE as the default desktop. The problem is KDE is affected with anything I do to invoke the old powersave behavior. If I use the intel_pstate=disable boot option and the older powersave scaling, everything in KDE launches horrifically slow.
Seems only KDE is affected. I also have TDE installed. TDE and Xfce are not affected by intel_pstate=disable and the older powersave frequency scaling.
Thus far the best I seem to do is use the intel_pstate=passive boot option and then in /etc/default/cpufreq use the ondemand option. The result though is CPU frequency continually jumping all over the place and no longer has any attributes of the old powersave mode. CPU frequency seems to always hover way above anything I saw in 14.2 and tends to hover near maximum at 3.x GHz.
Seems now the computer has become a foot warmer.
How to better configure this newer frequency scaling?
Off topic: I have considered a new system with a Ryzen APU but that is not going to happen soon. I need to tame this new pstate thing. Another option is disable monitoring CPU frequency with conky but the proverbial "ignorance is bliss" approach is not appealing.
intel_pstate can do powersave or performance (the last I read up on it). I disliked both so I went with powersave and setup rc.local to increase the min_perf_pct to give it enough oomph that I wanted. I think pstate sucks.
Check the minimum percentage of the cpu being used:
My goal is to favor power saving and keep CPU frequency low most of the time -- yet ensure everything in KDE launches immediately.
To be sure I am following correctly:
* Remove the intel_pstate=whatever option from the boot menu.
* Edit /etc/default/cpufreq to SCALING_GOVERNOR=powersave.
* Experiment with /sys/devices/system/cpu/intel_pstate/min_perf_pct.
The intel-pstate.txt documentation says:
For example the "performance" policy is similar to cpufreq's "performance" governor, but "powersave" is completely different than the cpufreq "powersave" governor. The strategy here is similar to cpufreq "ondemand", where the requested P-State is related to the system load.
I prefer the older powersave mode but KDE doesn't. If the best I can achieve is a pseudo ondemand then c'est la vie. The trick is ensuring the CPU idles most of the time but allows KDE software to launch immediately. I do not understand why CPU frequency is always high -- except to conclude that KDE is way more CPU intensive than folks admit or I have some processes not obvious to me that are hogging CPU cycles.
Quote:
I think pstate sucks.
Consoling words, thank you.
That same kernel document defines min_perf_pct:
min_perf_pct: Limits the minimum P-State that will be requested by the driver. It states it as a percentage of the max (non-turbo) performance level.
Gobbledygook.
I wish developers would stop fixing things that aren't broken.
My goal is to favor power saving and keep CPU frequency low most of the time -- yet ensure everything in KDE launches immediately.
To be sure I am following correctly:
* Remove the intel_pstate=whatever option from the boot menu.
* Edit /etc/default/cpufreq to SCALING_GOVERNOR=powersave.
* Experiment with /sys/devices/system/cpu/intel_pstate/min_perf_pct.
Yes and be careful because it is the percentage of CPU used. You are setting the minimum speed of your CPU by percentage used. Check cpufreq-info to see what it is set to as you adjust it. My relative's CPU is Skylake so this is what I did for them. I used to do this for my Ivy Bridge CPU but they removed pstate for me so I use intel_cpufreq with schedutil instead. I like it better. The last I checked intel_cpufreq wasn't available for Skylake.
Last edited by RadicalDreamer; 03-25-2023 at 05:04 PM.
So -- with intel_pstate=active (default) and SCALING_GOVERNOR=powersave, I need to tinker with the minimum frequency (as a percentage) to find where I can coax KDE to be responsive. That is, I can use intel_pstate powersave but a minimum frequency is needed to keep KDE responsive.
But that is not how I used to run the system. The ACPI powersave kept the system idling at 800 MHz yet everything responded well as needed. By setting a minimum frequency I never will again be able to have the system idle at 800 MHz. Instead the system will run between some minimum frequency and maximum of 3300 MHz.
My understanding of reading rc.cpufreq and after finding your original thread is that SCALING_GOVERNOR=performance is supposed to provide faster computers to satiate the gamers, yet somehow regulate a lightly used system to idle mode most of the time. That has not been my observation. With the defaults my system seems to run near full throttle (3300 MHz) most of the time.
I have tried reverting to the ACPI version of powersave (intel_pstate=disable). Both TDE and Xfce don't seem to care, but then KDE becomes almost unusable. Click -------- and wait.
I suppose that is the core problem -- KDE seems designed with presumptions of having only a fast system.
For anybody reading this thread, by tinkering I have learned that the /sys/devices/system/cpu/intel_pstate/min_perf_pct option cannot be set to a value lower than the minimum frequency supported in the CPU. On my Skylake the frequency range is 800 to 3300 MHz. Divide 800 by 3300 to arrive at a rounded-off 24%. That is the minimum value this option will allow.
So far I am using intel_pstate=passive, /etc/default/cpufreq = SCALING_GOVERNOR=powersave, and leaving /sys/devices/system/cpu/intel_pstate/min_perf_pct at the default 24 percent (800 MHz).
This configuration seems to keep the Conky display at 800 to 1200 MHz and jumping higher as needed. Important is KDE seems content with these options, but I haven't rebooted and started from scratch -- only modified the options in on-the-fly. No further testing yet pursued.
While monitoring CPU frequency is more precise with the computer and a plot or graph, through the years using Conky was sufficient to "eyeball" that the system was idling in powersave mode at about 800 MHz most of the time. I do not really need a plot or graph -- whatever Conky displays should be sufficient to gauge at how the CPU is idling.
All very frustrating. I am hoping this combination of settings is finally the end of this silly problem.
If I follow your discussion, then seems in my previous post I am on the right track. I checked /sys/devices/system/cpu/cpufreq/policy*/scaling_driver and the CPU is configured to intel_cpufreq.
As mentioned, thus far today with no reboots to start and test fresh, my changes seems to be emulating closer to the original ACPI powersave. I have been at the computer for quite a while with a lot of writing and emails. I have been continually watching Conky and seems that CPU frequency is now behaving the way I prefer.
If I understand correctly, all I need is to continue using intel_pstate=passive as a boot parameter and keep /etc/default/cpufreq = SCALING_GOVERNOR=powersave. No other changes seem needed.
I'll see how this all goes for a few days before deciding the problem is solved.
I tried combinations of intel_pstate=active, =passive and =disable (acpi-cpufreq), along with powersave, performance, and ondemand.
Using intel_pstate=active and performance seemed to never enter any kind of power saving mode. Conky seemed to always display at more than 3000 MHz. Likewise with intel_pstate=disable and using acpi-cpufreq with performance.
Using either intel_pstate=passive or acpi-cpufreq with powersave triggered KDE into launching everything slow. On my system KDE just does not like any kind of powersave mode. Nothing crashed but waiting 3 to 4 seconds for everything to launch is mind-numbing. I will be content to learn that I am not configuring something correctly to cause the delays.
Using ondemand with inel_pstate=passive or intel_pstate=disable, the latter of which triggers into acpi-cpufreq, seemed to result in palatable results. Everything in KDE launched normally and the Conky display seems sane.
In the end I decided I preferred the intel_pstate=disable and ondemand combination. After many years of using acpi-cpufreq and powersave, I will need a while to acclimate to Conky's CPU frequency display jumping all over much more than with powersave.
Sadly I did not pay attention to the cpufreq-info stats until after deciding to use the intel_pstate=disable and ondemand combination. The stats show the CPU frequency staying below 1200 MHz about 60% of the time along with no perceptible affect on desktop performance.
After about an hour and half of doodling and rebooting I decided this last combination would be best for me.
No major conclusions one way or another. A better trial would be running each of the different combinations for about 12 hours connected to a Kill-A-Watt meter along with some way to plot CPU fan speed and temperatures.
I think the statement in rc.cpufreq is misleading. Nothing I tried with intel_pstate and performance seemed to make any difference with respect to power saving.
I agree that the kernel support for intel_pstate make Slackware 15.0 slightly less attractive than 14.2 which had an older kernel which lacked support for intel_pstate.
The drawbacks are:
Cores running at higher frequencies and higher temperatures
No longer support for ignore_nice_load
Fortunately, for me it seemed to be a rather easy fix to boot with "intel_pstate=disable", but I have also made some more customizations.
Without "intel_pstate=disable" the kernel boots and gets settings from /etc/rc.d/rc.cpufreq. This means high frequencies at idle and no ignore_nice_load. With "intel_pstate=disable" my own custom settings in /usr/local/etc/rc.d/rc.cpufreq works, that file is called from my /etc/rc.d/rc.local.
I have the following settings in /usr/local/etc/rc.d/rc.cpufreq:
Code:
#!/bin/sh
# Fix cpu frequency adaption to load
/sbin/modprobe acpi-cpufreq 2>/dev/null && \
/sbin/modprobe cpufreq_ondemand && \
find /sys/devices/system/cpu -name scaling_governor -exec \
sh -c 'echo ondemand > {}' \; && \
echo CPU frequency will be adapted to load || \
echo No CPU frequency adaption on this machine...
echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load
echo 100 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
With the old ondemand governor CPU frequencies will be low at idle and the cores will get low temperatures.
My custom setting for ignore_nice_load will not increase CPU frequency for processes running nice, some people prefer it like me, some people don't mind if the CPU fan speed increases even though only a nice job is running.
My custom settings for sampling_down_factor and up_threshold have been done to make the system more responsive when going from idle to CPU usage.
I was using the following in my /etc/default/cpufreq for a while after messing around with intel_pstate and acpi-cpufreq trying to reduce sluggishness.
Code:
# cat /etc/default/cpufreq
# Conservative governor idles low and throttles up as needed:
SCALING_GOVERNOR=conservative
# Default min. freq. is too low my systems range is:
# 400MHz min - 2300MHz max
# At idle its running at 17.4% of max, and can be sluggish in response.
# Lets up the minimum to idle higher and have more response:
if [ "$SCALING_GOVERNOR" = "conservative" ]; then
# Low end idle speed in percent:
MIN_IDLE=40
LOGNAM=cpufreq
CPUPREFIX=/sys/devices/system/cpu
MIN_FREQ=$(( ($MIN_IDLE * $(cat $CPUPREFIX/cpu0/cpufreq/cpuinfo_max_freq) ) / 100 ))
echo "$LOGNAM: Trying to set minimum idle cpu to ${MIN_IDLE}% of max ($(( $MIN_FREQ / 1000 )) MHz)"
for cpu in $(ls $CPUPREFIX | grep '^cpu[0-9]\+')
do
echo $MIN_FREQ > $CPUPREFIX/${cpu}/cpufreq/scaling_min_freq
done
sleep 0.2
echo "$LOGNAM: Min freq is $(( $(cat $CPUPREFIX/cpu0/cpufreq/scaling_min_freq) / 1000 )) MHz ($(( ( $(cat $CPUPREFIX/cpu0/cpufreq/scaling_min_freq) * 100 ) / $(cat $CPUPREFIX/cpu0/cpufreq/cpuinfo_max_freq) ))% of max)"
fi
This was booting with intel_pstate=disable so I can use the conservative governor. Theres fixed steps available for setting the minimum idle freq but I just did a percentage and set that value. The governor will round to the closest available and use that.
Conservative on its own might suit your needs. I found I wanted to up the min percent a little, hence using the above code.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.