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

Didier Spaier · 09-12-2018, 02:38 PM

Quote:

Originally Posted by RadicalDreamer

I guess each to their own but I don't think a core should be going full blast all the time.

Maybe it depends what processes are running, and some running binary is written in such a way to make hard for the kernel to make a proper load balancing? Just speculating...

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

Quote:

Originally Posted by abga

Personally, I'm sure about experiencing the ramp-up lagginess, confirmed observations on 3 different systems (laptops) and you can also take a look over this imaginative and placebo biased graph:
https://www.phoronix.com/scan.php?pa...linux315&num=6
You can always choose your preferred governor:
https://www.linuxquestions.org/quest...ml#post5898048
And you can always take care about the CPU power consumption on your mobile device, pretty easy:
https://www.linuxquestions.org/quest...ml#post5901577

sorry, but the examples you bring

Quote:

Originally Posted by abga

...the issue (lagginess) starts to be evident when you do some tasks sporadically, that's browsing through the DE menus, browsing the internet, issuing some commands in the console, etc....

are non, desktop menu, depends on reading *.desktop files from disk, also, default desktop, KDE, has delay animation on the menu.

webpages? the cpu will go to speed faster than you get some KB of the site, ...

and the page you refer to

Quote:

The performance governors also led to the best performance-per-Watt with the increased power usage / higher CPU power state generally being worth the performance gains.
Those more concerned about power usage / battery life over performance should see how the Intel P-State powersave and ACPI CPUfreq conservative modes work out for their needs.

performance in opening desktop menus with animation to last at least time x until open, sure.

you just confirm what I was writing, but thanks for that.

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

Quote:

Originally Posted by RadicalDreamer

It caused problems with the computer in question after I restarted the computer twice but that computer has serious problems anyway. Performance setting triggered it. So Slackware should cater to low/medium-end CPUs with adequate cooling? I think upping the min freq would make more sense for these older computers. That is what I'll do when the time comes:

https://www.phoronix.com/forums/foru...nux-3-15/page2

This makes sense because what min_perf_pct does is multiply the max frequency with the percentage selected. My max is 3.9 GHZ. min_perf_pct is set to 41 so my min freq is 1.6 GHZ which it is. I set it to 50 and my min freq for all cores is now 2.00 GHZ.

I guess each to their own but I don't think a core should be going full blast all the time. There has to be a better way to do this. I don't think Slackware should be shipping with this but it is our BDFL's decision. If the min frequencies isn't good enough then up it by a percentage is my answer to the performance problem. At least I figured out my solution to keeping my aging hardware relevant.
https://www.kernel.org/doc/html/v4.1...el_pstate.html

I'm only using Slackware 14.2 stable with the kernel 4.4.153 on x86 and ran all the tests/ did all observations under this version.
I wasn't happy myself with the performance governor on intel_pstate, because in my case I had both cores at max speed all the time on all systems and due to the temperature increase (of a few degrees 48-49 to 52-53) my fans were always spinning. I took a radical measure and disabled the intel_pstate driver for good:
https://www.linuxquestions.org/quest...ml#post5900930
In this other post I mentioned that there are more improvements to the intel_pstate driver that are not available in 4.4.153 and I'm considering moving to the kernel Slackware -current provides.
https://www.linuxquestions.org/quest...ml#post5899390

I'm wondering on what Slackware/kernel version did you observe that core staying at max speed?

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

Quote:

Originally Posted by SCerovec

Using the 4.18.x for a week now (our unofficial build).

I'm amused how this does not apply to the 4.18.x as it does to the 4.4.x series Slackware 14.2 still supports.

Amusing dead horse racing

Have you enabled all CPU PM drivers in your unofficial kernel build?
CONFIG_CPU_FREQ

RadicalDreamer · 09-12-2018, 03:33 PM

Quote:

Originally Posted by abga

I'm only using Slackware 14.2 stable with the kernel 4.4.153 on x86 and ran all the tests/ did all observations under this version.
I wasn't happy myself with the performance governor on intel_pstate, because in my case I had both cores at max speed all the time on all systems and due to the temperature increase (of a few degrees 48-49 to 52-53) my fans were always spinning. I took a radical measure and disabled the intel_pstate driver for good:
https://www.linuxquestions.org/quest...ml#post5900930
In this other post I mentioned that there are more improvements to the intel_pstate driver that are not available in 4.4.153 and I'm considering moving to the kernel Slackware -current provides.
https://www.linuxquestions.org/quest...ml#post5899390
I'm wondering on what Slackware/kernel version did you observe that core staying at max speed?

I am using Linux 4.14.69 x86_64 which is in Current.

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

Quote:

Originally Posted by a4z

sorry, but the examples you bring

are non, desktop menu, depends on reading *.desktop files from disk, also, default desktop, KDE, has delay animation on the menu.

webpages? the cpu will go to speed faster than you get some KB of the site, ...

and the page you refer to

performance in opening desktop menus with animation to last at least time x until open, sure.

you just confirm what I was writing, but thanks for that.

In some of my previous posts I speculated that the ramp-up delay is coming from the intel_pstate driver while under the powersave governor, aggressively putting the CPU in some deep sleep mode by using the C-states, because only the frequency scaling couldn't cause such a delay in responsiveness.

I didn't confirm anything you wrote before in your post #98, was not even my intention, I just tried to help you with your frustration: "I would say: welcome to the world of imaginations and placebos"
But now, reading your reply I feel sorry for trying to help in the first place and I'm afraid I might be not qualified for the help you look needing.
I'm still happy that you quoted a relevant sentence from that phoronix article:
"The performance governors also led to the best performance-per-Watt with the increased power usage / higher CPU power state generally being worth the performance gains. "

RadicalDreamer · 09-12-2018, 03:38 PM

Quote:

Originally Posted by Didier Spaier

Maybe it depends what processes are running, and some running binary is written in such a way to make hard for the kernel to make a proper load balancing? Just speculating...

Here is "performance" governor on run level 3 on my 3770 after a few minutes:

Code:

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 4294.55 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 2.20 GHz.
analyzing CPU 1:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 4294.55 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 3.89 GHz.
analyzing CPU 2:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 2
  CPUs which need to have their frequency coordinated by software: 2
  maximum transition latency: 4294.55 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 3.90 GHz.
analyzing CPU 3:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 3
  CPUs which need to have their frequency coordinated by software: 3
  maximum transition latency: 4294.55 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 2.54 GHz.
analyzing CPU 4:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 4
  CPUs which need to have their frequency coordinated by software: 4
  maximum transition latency: 4294.55 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 3.90 GHz.
analyzing CPU 5:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 5
  CPUs which need to have their frequency coordinated by software: 5
  maximum transition latency: 4294.55 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 3.89 GHz.
analyzing CPU 6:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 6
  CPUs which need to have their frequency coordinated by software: 6
  maximum transition latency: 4294.55 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 3.88 GHz.
analyzing CPU 7:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 7
  CPUs which need to have their frequency coordinated by software: 7
  maximum transition latency: 4294.55 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 1.69 GHz.

One interesting thing I found out is that the freq runs higher in powersave in runlevel 3 than it does Plasma 5.

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

Quote:

Originally Posted by RadicalDreamer

I am using Linux 4.14.69 x86_64 which is in Current.

Thanks, I'll try to load it tomorrow if I find some time and check how it performs, curious if it'll keep the cores maxed out.

RadicalDreamer · 09-12-2018, 03:52 PM

Quote:

Originally Posted by abga

Thanks, I'll try to load it tomorrow if I find some time and check how it performs, curious if it'll keep the cores maxed out.

Try this too:

Code:

echo 44 > /sys/devices/system/cpu/intel_pstate/min_perf_pct

I upped my min_perf_pct 3 points from 41 and I can tell a difference by upping the min freq 200 mhz. The above code is now a resident in my rc.local!

Didier Spaier · 09-12-2018, 03:55 PM

@RadicalDreamer: to me, your results are a reminder that whilst cpufreq can set the frequency independently for each CPU considering its load and the policy chosen, it of course has no influence on the load of that CPU. Anyway my remark was probably off topic, sorry about that.

SCerovec · 09-12-2018, 03:56 PM

Code:

Linux version 4.18.6 (dusk@dusk) (gcc version 8.2.0 (GCC)) #1 SMP Wed Sep 5 07:29:56 UTC 2018
Command line: \\boot\vmlinuz-generic-4.18.6 root=/dev/sda2 vt.default_utf8=1 vga=normal ro 4 spec_store_bypass_disable=on ro initrd=boot\initrd-4.18.6.gz

I hope this answers all the above questions?
just in case:

Code:

uname -a
Linux riga 4.18.6 #1 SMP Wed Sep 5 07:29:56 UTC 2018 x86_64 Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz GenuineIntel GNU/Linux

4GB 1333 DDR3 RAM

added the /proc/config.gz (added .txt for rules)

abga · 09-12-2018, 04:01 PM

Quote:

Originally Posted by RadicalDreamer

Try this too:

Code:

echo 44 > /sys/devices/system/cpu/intel_pstate/min_perf_pct

I upped my min_perf_pct 3 points from 41 and I can tell a difference by upping the min freq 200 mhz. The above code is now a resident in my rc.local!

Thanks for the hints!
You made use of cpufreq-info to check the status of your cores, but I'd also like to suggest (if you haven't done it before) monitoring your CPU while idle and under intel_pstate->performance with:

Code:

watch -n 1 "sensors && grep \"cpu MHz\" /proc/cpuinfo"

Observe if the core(s) are continuously maxed out.

SCerovec · 09-12-2018, 04:05 PM

on 4.18.x the freq is jumping quite vivid FWIW - quite more than on 4.4.x series where it usually just hanged there

abga · 09-12-2018, 04:11 PM

Quote:

Originally Posted by SCerovec

Code:

Linux version 4.18.6 (dusk@dusk) (gcc version 8.2.0 (GCC)) #1 SMP Wed Sep 5 07:29:56 UTC 2018
Command line: \\boot\vmlinuz-generic-4.18.6 root=/dev/sda2 vt.default_utf8=1 vga=normal ro 4 spec_store_bypass_disable=on ro initrd=boot\initrd-4.18.6.gz

I hope this answers all the above questions?
just in case:

Code:

uname -a
Linux riga 4.18.6 #1 SMP Wed Sep 5 07:29:56 UTC 2018 x86_64 Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz GenuineIntel GNU/Linux

4GB 1333 DDR3 RAM

added the /proc/config.gz (added .txt for rules)

Your CPU is Sandy Bridge architecture and according to the kernel doc, intel_pstate should be used:
https://www.kernel.org/doc/html/v4.1...el_pstate.html
"intel_pstate is a part of the CPU performance scaling subsystem in the Linux kernel (CPUFreq). It is a scaling driver for the Sandy Bridge and later generations of Intel processors. Note, however, that some of those processors may not be supported. [To understand intel_pstate it is necessary to know how CPUFreq works in general, so this is the time to read CPU Performance Scaling if you have not done that yet.]"
https://en.wikipedia.org/wiki/Sandy_Bridge

What's the output of?

Code:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

And you can only verify in the kernel config file if all the CPU PM drivers were enabled, in the section: CONFIG_CPU_FREQ

P.S. Just checked the config file you attached, sorry observed it late, and you have the intel_pstate driver enabled:

Code:

#
# CPU frequency scaling drivers
#
CONFIG_X86_INTEL_PSTATE=y

RadicalDreamer · 09-12-2018, 04:16 PM

Quote:

Originally Posted by Didier Spaier

@RadicalDreamer: to me, your results are a reminder that whilst cpufreq can set the frequency independently for each CPU considering its load and the policy chosen, it of course has no influence on the load of that CPU. Anyway my remark was probably off topic, sorry about that.

I think you are on topic. That is true. It would be nice if the loads were spread out more rather than the performance governor maxing out a couple cores. In my mind at the moment the minimum CPU frequency baseline is too low and needs to be upped so general computer usage is snappy with powersave. I never looked at this stuff until recently after getting Rise of the Tomb Raider (it tells you to put the CPU on performance and it takes a minute for it to stop being choppy with powersave) and this thread so I'm a complete newbie.