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

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

Quote:

Originally Posted by abga

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.

The cores bounce around on my 3770 from min to max and around half of the time they are either max or above 3 GHZ I think. Core 0 seems to be used the most because its temperatures are 43-47 C which isn't bad. The cores looked to me like they stayed near max more idling on runlevel 3 than on Plasma 5 or maybe it was my imagination because there was a lot of movement with the frequencies.

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

Quote:

Originally Posted by RadicalDreamer

The cores bounce around on my 3770 from min to max and around half of the time they are either max or above 3 GHZ I think. Core 0 seems to be used the most because its temperatures are 43-47 C which isn't bad. The cores looked to me like they stayed near max more idling on runlevel 3 than on Plasma 5 or maybe it was my imagination because there was a lot of movement with the frequencies.

Thanks for testing this, I'll try the kernel -current is providing with the improved intel_pstate driver tomorrow, it's late here now. As stated before, I had all cores maxed out and fans spinning (lowest speed) under 4.4.153 (and older - last years) with intel_pstate->performance.
https://www.linuxquestions.org/quest...ml#post5900930

SCerovec · 09-12-2018, 06:55 PM

Quote:

Originally Posted by abga

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

Code:

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

Just saying I noticed how much better it behaves (I have all times an CPU frequency readout on screen no matter which OS i use).

So both placebo and dashboard align in "feels more good"

gus3 · 09-12-2018, 10:28 PM

@abga, I know this is a few days late, but my comment about:

Quote:

turn the d@mn thing off, go outside & play.

wasn't referring to an individual CPU frequency governor. I was talking about the whole d@mn computer.

SCerovec · 09-13-2018, 02:32 AM

Quote:

Originally Posted by gus3

@abga, I know this is a few days late, but my comment about:

wasn't referring to an individual CPU frequency governor. I was talking about the whole d@mn computer.

I was amused how they missed it, and dissected it "wood from the trees" style

anyhow, when IRL strikes, I usually leave the computers in their most efficient power state -> "neglected"

gegechris99 · 09-13-2018, 03:26 PM

Quote:

Originally Posted by abga

Your approach, isolating the ac_adapter* event and using a dedicated script for handling it, is interesting and as you said appropriate for users who might want to opt out. In your case, this needs to be documented, otherwise nobody will know about it.

I doubt that the changes I/you proposed will ever make their way upstream and I'm sorry now for not opening a new thread for this particular CPU PM improvement proposal. I was caught in the feedback "frenzy" and started to look for a solution, found one and documented it in post #71.

As a first step, I created an entry in my LQ blog: ACPI configuration to handle AC adapter events

I'm no technical writer but I may try to create an article on SlackDocs.

abga · 09-15-2018, 02:53 PM

@gus3
In post #66 you said you felt inadequate, changed your mind ?

But then, in your first intervention ( post #50) you unintentionally raised a valid point. Why not disable the OS level CPU PM control and let the BIOS/Intel ME default algorithms decide what to do best, blame the HW manufacturer if your system is performing unsatisfactory.

@SCerovec
In your post #101 you said:

Quote:

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.

I was asking myself what CPU PM are you using and what governor is active, because these were the most relevant pieces of information that were missing from that post. Meanwhile you confirmed that you're using the intel_pstate driver but still missed to present the actual governor:

Code:

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

In post #40 I highlighted the changes in the intel_pstate driver (intel_pstate.c) that are not available in 4.4.y and considered that some of those changes will improve the behavior of the driver. I can confirm now, with my actual test on 4.14.69, that intel_pstate->performance is behaving better, however, intel_pstate->powersave is still laggy.

@gegechris99
I read your blog post and it's good quality, a little too much of "I & my" IMO, try not to use first person in a technical doc

Looking at the official repository, I couldn't find too much related to PM:
http://docs.slackware.com/howtos:slackware_admin:start
But only this about hibernation:
http://docs.slackware.com/howtos:sla...in:hibernation
I suggest to create a generic How-To about PM and only fill in your chapter about the CPU PM (focus only on intel_pstate & acpi-cpufreq (there could be other drivers)), that'll pave the way for other contributors to add some additional PM tweaks for other system components. Although, as I said before, on modern systems these other components have their own autonomous HW/Firmware/BIOS PM. I know I always have to manually disable the HDD PM on laptops, stopping that annoying click (parking the heads) and the spin-up/down noise.

____

I ran the same test from #43 on Slackware 14.2 with the -current kernel 4.14.69, intel_pstate set on performance and I'm happy with the behavior observed. The frequencies were dynamically changing on all cores, on the Skylake core i7 I also observed the turbo-boost enabled a few times while compiling, the CPU fans were spinning only from time to time and the system performance was good. intel_pstate set on powersave is still laggy.

Code:

Every 1.0s: uname -r && sensors && grep "cpu MHz" /proc/cpuinfo
4.14.69
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +50.0°C  (high = +100.0°C, crit = +100.0°C)
Core 0:        +50.0°C  (high = +100.0°C, crit = +100.0°C)
Core 1:        +48.0°C  (high = +100.0°C, crit = +100.0°C)

dell_smm-virtual-0
Adapter: Virtual device
Processor Fan:    0 RPM
CPU:            +50.0°C
Ambient:        +52.0°C
Other:          +49.0°C
GPU:            +47.0°C

cpu MHz         : 1549.835
cpu MHz         : 1632.892

It looks like the old intel_pstate driver from 4.4.y is suffering from some sort of obsessive-compulsive disorder, either obsessively killing the CPU on powersave or maxing out the frequencies on performance. I believe now that the new rc.cpufreq default intel_pstate->performance is appropriate only for Slackware -current with the new kernel (updated intel_pstate driver).

If you want to dig further into this, here are some more interesting articles:
- Lenovo study - page 14-15 stating that the beloved Intel ME is actually in control over the CPU PM and might not honor what the OS (intel_pstate driver) is requesting:
https://lenovopress.com/lp0870.pdf
- Arch, recommending intel_pstate->performance:
https://wiki.archlinux.org/index.php...ling_governors
- Suse considering the powersave governor inefficient: Section: 11.2 In-Kernel Governors:
https://doc.opensuse.org/documentati...ower.governors
- Ubuntu - filing an actual bug report for the intel_pstate set on powersave, changing it to performance:
https://bugs.launchpad.net/ubuntu/+s...x/+bug/1579278
- MySQL performance impact study related to the CPU PM governors, favoring intel_pstate->performance:
https://dzone.com/articles/how-cpu-g...-affects-mysql

gegechris99 · 09-16-2018, 09:53 AM

Quote:

Originally Posted by abga

@gegechris99
I read your blog post and it's good quality, a little too much of "I & my" IMO, try not to use first person in a technical doc

Thanks for feedback.

Seeing your latest test results, I installed -current kernel (4.14.69) on Slackware64 14.2

After a day of using the 4.14 kernel, I do confirm that the PM is much better than with kernel 4.4.
With intel_pstate->performance, I do notice that the fan stops running after some time when the laptop is not doing much. The fan didn't stop with kernel 4.4. That, alone, is a significant improvement.
With intel_pstate->powersave, the CPU frequency seems to fluctuate in the range 1.2-2GHz which is higher than the 0.8-1GHz observed with kernel 4.4. My perception (not a good metric, I admit) is that the system is more responsive than with kernel 4.4 in powersave mode.

I will stay for a while with kernel 4.14 on Slackware64 14.2.

CPU:

Code:

cpu family      : 6
model           : 60
model name      : Intel(R) Core(TM) i3-4100M CPU @ 2.50GHz
stepping        : 3
microcode       : 0x25

With performance governor:

Code:

$ uname -r && sensors && grep "cpu MHz" /proc/cpuinfo
4.14.69
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +49.0°C  (high = +84.0°C, crit = +100.0°C)
Core 0:        +47.0°C  (high = +84.0°C, crit = +100.0°C)
Core 1:        +49.0°C  (high = +84.0°C, crit = +100.0°C)

cpu MHz         : 2494.319
cpu MHz         : 2494.279
cpu MHz         : 2500.479
cpu MHz         : 2495.248

With powersave governor:

Code:

$ uname -r && sensors && grep "cpu MHz" /proc/cpuinfo
4.14.69
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +49.0°C  (high = +84.0°C, crit = +100.0°C)
Core 0:        +46.0°C  (high = +84.0°C, crit = +100.0°C)
Core 1:        +49.0°C  (high = +84.0°C, crit = +100.0°C)

cpu MHz         : 1504.424
cpu MHz         : 1579.207
cpu MHz         : 1568.327
cpu MHz         : 1591.350

SCerovec · 09-16-2018, 10:59 AM

@abga
both "performance" and "powersave"

SCerovec · 09-19-2018, 05:55 AM

In

Code:

/usr/src/linux/

I found:

Code:

# cd tools/power/x86/x86_energy_perf_policy
# make
# make install

gave me access to man x86_energy_perf_policy

a good read regarding Intel x86
just my 2c.

abga · 09-19-2018, 01:01 PM

Interesting, it looks like you can influence/override what the intel_pstate driver / Intel ME+BIOS is doing, by directly accessing the CPU Model Specific Register (MSR).
https://itpeernetwork.intel.com/how-...base-on-linux/
https://access.redhat.com/documentat...gy_perf_policy
https://lore.kernel.org/patchwork/patch/735720/
https://lore.kernel.org/patchwork/patch/655892/
https://forum.manjaro.org/t/kernel-p...ot-issue/42828

So, you already have 3 components/layers for tuning the CPU, intel_pstate(driver) & x86_energy_perf_policy(kernel subsystem) on OS/user level and Intel ME with a mind of its own on HW level, concurrently trying to mess up with the poor little CPU.

SCerovec · 09-19-2018, 03:22 PM

Provided the intel_pstate isn't loaded by default, this makes for two.
Add to that the x86_energy_perf_policy is actually user space tool and has to be run as root - also used optionally.
This makes one - IME left alone per default?

abga · 09-19-2018, 03:54 PM

Quote:

Originally Posted by SCerovec

Provided the intel_pstate isn't loaded by default, this makes for two.
Add to that the x86_energy_perf_policy is actually user space tool and has to be run as root - also used optionally.
This makes one - IME left alone per default?

intel_pstate + x86_energy_perf_policy are indeed the two components on OS level and the third, Intel ME on HW level, which is enabled in all systems starting from 2009, that includes Sandy Bridge (2011) where intel_pstate already kicks in. I considered Intel ME together with the BIOS as one component, because the BIOS only provisions the autonomous Intel ME with some user defined values.
I only learned that the Intel ME might not honor what intel_pstate is asking while reading the Lenovo pdf from post #127 (first link in the bottom section).
https://en.wikipedia.org/wiki/Intel_Management_Engine
https://en.wikipedia.org/wiki/Intel_Sandy_Bridge

SCerovec · 09-20-2018, 02:47 AM

Well, usually systems are split apart because of some policy mismatch...

Effectively meaning the IME takes precedence over OEM vendor's BIOS?

And the x86_energy_perf_policy tool seems to be part of the Intel's Linux support effort?

or?

abga · 09-20-2018, 09:46 AM

Quote:

Originally Posted by SCerovec

Effectively meaning the IME takes precedence over OEM vendor's BIOS?

Related to the CPU PM, not precedence over the BIOS, but over the OS level drivers/policies. It looks like Intel ME is in charge with the PM of the CPU and not the BIOS (although Intel ME should consider the user specified PM values in the BIOS), if I'm about to follow these observations:
https://lenovopress.com/lp0870.pdf
- page 15:
" Even though the governor is set as powersave and it implies that the OS hints are not very aggressive, Intel ME does not fully honor OS hints and relies more on its performance counter. "

Quote:

Originally Posted by SCerovec

And the x86_energy_perf_policy tool seems to be part of the Intel's Linux support effort?

It looks like that, at least for the capable CPUs:
https://lkml.org/lkml/2010/9/28/246

In your previous post, you stated:

Quote:

Add to that the x86_energy_perf_policy is actually user space tool and has to be run as root - also used optionally.

It is indeed optional, but its usage looks to be encouraged/recommended:
https://access.redhat.com/documentat...gy_perf_policy
https://itpeernetwork.intel.com/how-...base-on-linux/