LinuxQuestions.org - [SOLVED] Suggestion: use "performance" CPU frequency governor

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Suggestion: use "performance" CPU frequency governor (https://www.linuxquestions.org/questions/slackware-14/suggestion-use-performance-cpu-frequency-governor-4175637326/)

Quote:

Originally Posted by Darth Vader (Post 5901296)

Yeah, man! Way to go! :D

Let's complicate the rookies life even more! :thumbsup:

Well, tell that to Intel for only knowing black & white, either lazy (comatose-level) powersave or maxing-out the CPU frequency with performance (still some active PM).

P.S. On your edit, after I replied, see #39 from this thread.

Quote:

Originally Posted by abga (Post 5901292)

Personally, I'm fine with the performance of acpi-cpufreq->ondemand on my Intel CPUs and I'm not noticing any difference compared to intel_pstate->performance, other than having the CPU fans stopped when the system is idle. It might be that the intel_pstate is more aggressive, but I can't find any reference to that, only believing you. The "aggressiveness" of intel_pstate->performance I observed was keeping the CPU frequency maxed out and my CPU fans constantly spinning, at their lowest speed I must admit. The responsiveness is the same and once I start hammering the CPU with some processes the performance is also the same.

Interesting.

From my measurements, intel_pstate can run all four cores at their maximum turbo frequency (2.53GHz), whereas acpi-cpufreq could do that on only one core, dropping to the rated frequency (2.00GHz) when all cores were active. This was the case a few years ago - I haven't tried acpi-cpufreq since then.
Ed

Quote:

Originally Posted by EdGr (Post 5901302)

Just for clarification, I only run on laptops ATM (Haswell,Broadwell) and none of these have the Intel Turbo Boost enabled.
https://en.wikipedia.org/wiki/Intel_Turbo_Boost

You should try again acpi-cpufreq if you have CPUs that can go over the (normal) maximum.
This might be useful:
https://www.kernel.org/doc/Documenta...freq/boost.txt

EDIT:
The Skylake CPU has Turbo Boost but only available on one core and you're right, I didn't pay attention to that, acpi-cpufreq->ondemand doesn't look to make use of it, or maybe I'm not stressing the CPU enough.
https://ark.intel.com/products/88192

Quote:

Originally Posted by abga (Post 5901297)

Well, tell that to Intel for only knowing black & white, either lazy (comatose-level) powersave or maxing-out the CPU frequency with performance (still some active PM).

except the concrete ones I posted where I switch to performance on purpose when I need it, still no meaning full use case other than 'I want my CPU running hot'
maybe Intel came to the same conclusion as I, a cool CPU, less power consumption, no running FANs, max battery life if mobile, this is useful, and the rest is just need in extreme situations, where not even gaming , video editing, running Slackbuilds, ... makes a measurable different for having always the performance setting. Anyhow, this are just my 2 cents, I can edit a config file, now I know about this default, so I don't care too much

Quote:

Originally Posted by abga (Post 5901307)

I mis-remembered the Sandy Bridge one-core turbo frequency.

Here are my current measurements. Frequency is quoted in GHz as base, one-core turbo boost, and all-core turbo boost. All machines are running with the performance governor.

Core i7-930, Nehalem (desktop)

4 cores
acpi-cpufreq
Frequency: 2.8, 3.069, 2.936

Core i7-2630QM, Sandy Bridge (laptop)

4 cores
intel_pstate
Frequency: 2.0, 2.887, 2.59

Core i7-5960X, Haswell-E (desktop)

8 cores
intel_pstate
Frequency: 3.0, 3.495, 3.295

These machines are performing as advertised.

For background, I invented the technology that became Turbo Boost. That is why I am interested in delivered performance.
Ed

Quote:

Originally Posted by a4z (Post 5901316)

I was backing this change up because the powersave governor is lazy and I observed that on all my systems, years ago, set it on performance and also doing it on other systems I install. The CPU is not getting that hot on performance, but only a few degrees (under 5), unfortunately enough to trigger the fan on low speed and that was my personal issue. Try it for yourself and see if you're luckier than me.

In my arguments I was focusing on experience, and I already provided some in my previous posts. Main idea is that you do work on a computer and you expect it to be responsive and perform well. On a mobile computer you always need to take additional measures in order to tune the power consumption, configuring the governor is one of them and you have both the information and the possibility to do so.
I don't know what conclusions Intel came to, but I'm not happy with the limited flexibility/choices they came up with and I speculated in a previous post that maybe they were asked to provide a comatose-level of PM for the "cloud computers" that are never used and thus came up with the powersave.

These changes should have been done in Slackware 14.2 stable, the only one I'm running on x86 and the one I was using to provide feedback&test results, where you have an older kernel and the rc.cpufreq script is (still) broken, or inconsistent, or not optimal if you're too sensible and prefer an euphemism. The rc.cpufreq doesn't handle the governors for intel_pstate properly, providing the (default) ondemand governor for intel_pstate, which doesn't recognize it and uses its default powersave.
Related to my observations, I'm still not sure why under ~20% load, the CPU was not dropping its frequency with the performance governor as this governor (should) supports dynamic scaling. But maybe all these new intel_pstate driver developments and updates should get manually merged into the 4.4.x kernel.

Slackware -current is using a newer kernel already containing some improvements for the intel_pstate driver and by the time it'll turn into Slackware 15, with maybe some newer kernel tree and further intel_pstate improvements, the powersave governor might perform better and be suitable for use. Who knows, maybe Intel will come to some other conclusions and provide an intermediate "ondemand-like" governor. I haven't done any tests with Slackware -current but I'm starting to consider using the the kernel it provides for my Slackware 14.2 systems and ditching the 4.4.y.

My last 2 cents, I already had too much of this ;)

Quote:

Originally Posted by EdGr (Post 5901321)

4 cores
acpi-cpufreq
Frequency: 2.8, 3.069, 2.936

Core i7-2630QM, Sandy Bridge (laptop)

4 cores
intel_pstate
Frequency: 2.0, 2.887, 2.59

Core i7-5960X, Haswell-E (desktop)

8 cores
intel_pstate
Frequency: 3.0, 3.495, 3.295

These machines are performing as advertised.

For background, I invented the technology that became Turbo Boost. That is why I am interested in delivered performance.
Ed

Congrats for the invention.
My only Turbo Boost enabled CPU - 6600U can only use one core at the maximum turbo frequency (one-core turbo boost):
https://en.wikipedia.org/wiki/Skylak...ile_processors
Any tests I'll do would maybe be irrelevant, and ATM I'm stuck with the acpi-cpufreq and not considering to change it back to intel_pstate, at least not with the 4.4.x kernel.
As mentioned before, I'm not seeing the 3.40GHz turbo frequency with acpi-cpufreq and I'm not sure if it's me not pushing enough the CPU, although I started some compilations, or it's the acpi-cpufreq not able to tune this turbo frequency. Actually, I don't really care TBH with you, I'm happy with acpi-cpufreq and this thread was about intel_pstate and should remain about it and not about my personal comparisons and preferences. :)

From when the acpi-cpufreq driver with the ondemand governor was no longer fit for Intel CPUs:
https://www.phoronix.com/scan.php?pa...tem&px=MTM3NDQ

How about to remove that customization for Intel "performance" and just to leave to the proud Intel Gurus to customize to their beloved "performance" via "/etc/default/cpufreq" ?

Faulty or not, snail-ish or not, that "ondemand" governor brings up a functional system. Let's leave the tuning of dragster rigs right to users.

That will be more Slackware-ish... ;)

Or we can try to write an A.I. on bash scripts, to super-control that overpriced Intel crap, err... CPUs.

With all the feedback about this change I started to get worried about the use of mobile computers while on batteries with the default CPU governor configured on ondemand or performance, due to the increased power consumption of the CPU.
In this respect, when running on batteries, the default ondemand governor for acpi-cpufreq is also not optimal, powersave should be used instead.

In trying to fix this, I was looking for an automated solution to switch the governor when running on AC or battery, by only using the standard tools&toys Slackware is providing.
By not having any AI available to help me but only my NI(natural), I started to dig for infos&ways to obtain this automation.
This was also considered a long time ago here on LQ, but not really resolved:
https://www.linuxquestions.org/quest...attery-391686/

I started with pm-tools, another one of those well documented FreeDesktop projects and was not confident enough in my understanding over how it is triggered and how to use it properly, therefore I dumped it. Some info about it for more "courageous" people:
https://pm-utils.freedesktop.org/wiki/
Here is a solution built upon pm-utils:
https://forums.fedoraforum.org/showt...-cpu-governors
And there are some scripts already available in /usr/lib(64)/pm-utils/power.d/ that can be modified, made executable and copied into /etc/pm/power.d/

Finally, I considered using the /etc/rc.d/rc.cpufreq together with the (more mature and better documented) acpid daemon with its /etc/acpi/acpi_handler.sh script for handling PM events.
Inspiration:
https://wiki.archlinux.org/index.php...th_ACPI_events
There are two situations I considered taking care of, first, if the computer starts on batteries, then the CPU PM governor should be set on powersave, and second, after finishing the boot process and acpid is running, automatically switching the CPU PM governor based on running on AC Power connect/disconnect events.
The first situation I could only resolve by modifying and using the /etc/rc.d/rc.cpufreq script, adding a conditional check, looking if the system is on AC or not.
The only issue with this is that I'm not 100% sure if /proc/acpi/ac_adapter/AC/state is a standard, TLDP documents it as such:
https://www.tldp.org/HOWTO/Ecology-H...anagement.html
Here is the modification (in bold) to the latest /etc/rc.d/rc.cpufreq script:

Code:

# For CPUs using intel_pstate, always use the performance governor. This also

# provides power savings on Intel processors while avoiding the ramp-up lag

# present when using the powersave governor (which is the default if ondemand

# is requested on these machines):

if [ "$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver 2> /dev/null)" = "intel_pstate" ]; then

  SCALING_GOVERNOR="performance"

fi



#Check if the system is running on battery, AC disconnected. If positive, set the governor on powersave. The acpid daemon must be running.

if [ -r /proc/acpi/ac_adapter/AC/state ] || [ -r /proc/acpi/ac_adapter/ACAD/state ] || [ -r /proc/acpi/ac_adapter/ADP1/state ] || [ -r /proc/acpi/ac_adapter/ADP2/state ]; then

 if grep -q "off-line" /proc/acpi/ac_adapter/A*/state; then

  SCALING_GOVERNOR="powersave"

 fi

fi



# If rc.cpufreq is given an option, use it for the CPU scaling governor instead:

if [ ! -z "$1" -a "$1" != "start" ]; then

  SCALING_GOVERNOR=$1

fi

For the second situation, automatically switching the CPU PM governor based on running on AC Power connect/disconnect events, I modified the /etc/acpi/acpi_handler.sh script.
I am handling both CPU PM drivers: acpi-cpufreq and intel_pstate, with ondemand for acpi-cpufreq and performance for intel_pstate as governors for when running on AC Power and the common (for both) powersave governor for when running on batteries.
Here is the modified /etc/acpi/acpi_handler.sh script (changes in bold):

Code:

#!/bin/sh

# Default acpi script that takes an entry for all actions

IFS=${IFS}/

set $@



case "$1" in

  button)

    case "$2" in

      power) /sbin/init 0

        ;;

      *) logger "ACPI action $2 is not defined"

        ;;

    esac

    ;;

  ac_adapter)

    case "$2" in

        AC*|AD*)

            case "$4" in

                00000000)

                    if [ -r /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ]; then

                    echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 1> /dev/null 2> /dev/null

                    logger "AC Power not available, setting CPU frequency scaling governor:  $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor)"

                    fi

                ;;

                00000001)

                    if [ -r /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ]; then

                    if grep -q "ondemand" /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors; then

                      echo "ondemand" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 1> /dev/null 2> /dev/null

                    else

                      echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 1> /dev/null 2> /dev/null

                    fi

                    logger "AC Power available, setting CPU frequency scaling governor:  $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor)"

                    fi

                ;;

            esac

        ;;

        *) logger "ACPI action undefined: $2" ;;

    esac

    ;;

  *)

    logger "ACPI group $1 / action $2 is not defined"

    ;;

esac

I tested this solution with both the acpi-cpufreq and intel_pstate drivers and couldn't find any glitches under Slackware 14.2 stable.
That doesn't mean you shouldn't test it yourselves before using it and provide feedback.

Have more fun with your mobile systems when on batteries! :)

Quote:

Originally Posted by abga (Post 5901577)

The only issue with this is that I'm not 100% sure if /proc/acpi/ac_adapter/AC/state is a standard

Unfortunately it's not standard. On my laptop:

Code:

$ ls /proc/acpi/ac_adapter

ADP1

Looking in various places, it seems that value can be AC, ACAD, ADP1, ADP2 (I was not able to find a proper reference).
Strange enough, the acpi_listen identifies my AC adapter as ACPI0003 (below events when I unplugged and then plug my AC adapter)

Code:

$ acpi_listen

ac_adapter ACPI0003:00 00000080 00000000

processor LNXCPU:00 00000081 00000000

processor LNXCPU:01 00000081 00000000

processor LNXCPU:02 00000081 00000000

processor LNXCPU:03 00000081 00000000

battery PNP0C0A:00 00000081 00000001

ac_adapter ACPI0003:00 00000080 00000001

processor LNXCPU:00 00000081 00000000

processor LNXCPU:01 00000081 00000000

processor LNXCPU:02 00000081 00000000

processor LNXCPU:03 00000081 00000000

battery PNP0C0A:00 00000081 00000001

So for me, your first script would not work but the second would work.

To be safe in your second script, the following change in bold red could be made as was done in this example

Code:

 ac_adapter)

    case "$2" in

        AC*|AD*)

@gegechris99
Thanks for the feedback!

I corrected both scripts now according to your points, in order to cover all the alternative naming.

Not happy with the long conditional check form /etc/rc.d/rc.cpufreq, just a cosmetic thing, but I couldn't come up with a working shorter format/globbing like:

Code:

if [ -r /proc/acpi/ac_adapter/A*/state ]

grep looks to be happy with /proc/acpi/ac_adapter/A*/state

Quote:

Originally Posted by abga (Post 5901613)

Not happy with the long conditional check form /etc/rc.d/rc.cpufreq, just a cosmetic thing, but I couldn't come up with a working shorter format/globbing like:

Code:

if [ -r /proc/acpi/ac_adapter/A*/state ]

grep looks to be happy with /proc/acpi/ac_adapter/A*/state

Maybe this:

Code:

for value in AC ACAD ADP1 ADP2; do

    if [ -r /proc/acpi/ac_adapter/$value/state ]; then

        if grep -q "off-line" /proc/acpi/ac_adapter/$value/state; then

            SCALING_GOVERNOR="powersave"

        fi

    fi

done

But is it aesthetically better??

Thanks for the hint Didier, I tried to avoid any loops or nestings and more importantly using find(overkill).
It looks like somewhere upstairs these are not tolerated, that's in case these suggestions/script modifications will ever make their way into the Slackware base.