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 :hattip:

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

What do you mean?

Probably he wants to says that that Intel CPUs works happily with "ondemand" governor under 4.18.x and later, then this entire thread is a dead horse racing.

I was thinking that too but I want confirmation!

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...

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. :rolleyes:
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.

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?

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

I am using Linux 4.14.69 x86_64 which is in Current.

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. "

Here is "performance" governor on run level 3 on my 3770 after a few minutes:
One interesting thing I found out is that the freq runs higher in powersave in runlevel 3 than it does Plasma 5.

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:
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!

@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 hope this answers all the above questions?
just in case:

4GB 1333 DDR3 RAM

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

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:
Observe if the core(s) are continuously maxed out.

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

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?
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:

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.

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

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" ;)

@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 :D

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

Documenting ACPI configuration
 

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.

@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:
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:
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.
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

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:
With performance governor:
With powersave governor:

@abga
both "performance" and "powersave"

In I found:
gave me access to man x86_energy_perf_policy

a good read regarding Intel x86
just my 2c.

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.

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

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?

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. "


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

In your previous post, you stated:
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/

@abga,
I only learned of it from sbotools, but as it stubbornly tried to download the 4.4.14 kernel source I decided to look around...

... and what do you know - it's shipped with every kernel source - mine is form 4.18.6 :D

all one has to do is make && make install to access it.

Thankfully Slackware is the best make && make install distro of them all...:hattip: