Linux 4.7 CPUFreq Schedutil Testing vs. P-State

[milkylainen]

So this goes to show that all cpu scalers are still shit, screw up loads in an indeterministic fashion while costing you more cycles to boot.
Hooray.

[dsmythies]

The test results in this article do not make sense to me. I do not understand why driver=acpi-cpufreq, governor=performance would ever get any different results than driver=intel_pstate, governor=performance. Of course, now the intel_pstate driver has different operating modes, depending on the processor, hwp and/or "get_target_pstate_use_performance" verses "get_target_pstate_use_cpu_load". Isn't it a bit premature to do any tests with kernel 4.7, since release candidate 1 (-rc1) won't even be out for another couple of weeks? I did some of the same tests on my system using kernel 4.6-rc7, and got results more consistent with what I expected.

Hardware:
Processor: Intel Core i7-2600K @ 3.40GHz (8 Cores), Motherboard: ASUS P8Z68-M PRO, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, Disk: 1000GB Seagate ST1000DM003-1ER1 + 1000GB Seagate ST1000DL002-9TT1, Graphics: Intel 2nd Generation Core Family IGP, Audio: Realtek ALC892, Network: Intel 82574L Gigabit Connection

Software:
OS: Ubuntu 16.04, Kernel: 4.6.0-rc7-stock (x86_64), Compiler: GCC 5.3.1 20160413, File-System: ext4, Screen Resolution: 1680x1050

LAME MP3 encoding:
intel_pstate powersave: 13.20 Seconds
intel_pstate performance: 13.11 Seconds
acpi-cpufreq ondemand: 13.13 Seconds
acpi-cpufreq performance: 13.10 Seconds

Timed Linux Kernel Compile:
intel_pstate powersave: 130.38 Seconds
intel_pstate performance: 128.09 Seconds
acpi-cpufreq ondemand: 129.27 Seconds
acpi-cpufreq performance: 128.25 Seconds

Apache Benchmark:
intel_pstate powersave: 19289.75 Requests / Second
intel_pstate performance: 19268.35 R/S
acpi-cpufreq ondemand: 18207.56 R/S
acpi-cpufreq performance: 18423.95 R/S

Summary:
LAME MP3 encoding: article got ~3X worse results with intel_pstate driver; I get ~ the same.
Timed Linux Kernel Compile: article got ~2.6X worse results with intel_pstate driver; I get ~ the same.
Apache Benchmark: article got ~~ 1.8X worse results with intel_pstate driver; I get ~ the same or even a little better.

[linuxforall]

If you look in the kernel thread at Arch forum, after pstate was introduced, many with i7 Haswell have complaints about heating and power consumption. This is comparatively less with same pstate in Ubuntu due to config Hz=250 in kernel as compared to Arch's 300. However with current 16.04LTS which uses kernel 4.4, idle frequencies for Haswell is up, even at idle the cores rarely hit anything below 2k on a i7 4790 and mostly they sit near turbo, its still not as bad as Arch where the cores never scale down and sits no turbo. The temp issue is being taken care by c states so most cores are at c7 just like in Arch. A good example here https://bbs.archlinux.org/viewtopic.php?id=193440

[gutigen]

Since I think 4.4 kernel I can't reach max frequency on 4005u Haswell with psate, it sits at 1.6 instead of 1.7 and also never changes to power save mode (always at max no matter what I do). On the other hand cpu_freq works just as expected. Running Arch.

[konkor]

There is gnome-extension to manage governors. New Version is supporting cpufrequtil and cpupower packages.
so you can find latest on GitHub:
(https://github.com/konkor/cpufreq)
or just install via Gnome Tweak Tool
(https://github.com/konkor/cpufreq/archive/master.zip)

[linuxforall]

Since I think 4.4 kernel I can't reach max frequency on 4005u Haswell with psate, it sits at 1.6 instead of 1.7 and also never changes to power save mode (always at max no matter what I do). On the other hand cpu_freq works just as expected. Running Arch.

Arch is on Kernel 4.5.3 currently.

[geearf]

4.5.4 for core and 4.6 for testing.

[gutigen]

Arch is on Kernel 4.5.3 currently.

I've said "since", cause this problem persist up to 4.6 standard kernel, however suprisingly linux-ck works fine with pstate Oo Something to do with 1000hz config?

[linuxforall]

I've said "since", cause this problem persist up to 4.6 standard kernel, however suprisingly linux-ck works fine with pstate Oo Something to do with 1000hz config?

In Arch its 300Hz config vs SUSE and Ubuntu as well as Debian's 250Hz. Graysky the creator of linux-ck discussed this on Arch forums and have posted graphs of 250vs300, ck-kernel has 250 setting.

Another interesting study of intel_pstate vs cpufreq https://www.percona.com/blog/2016/05...r-performance/

[RickXy]

Looking at these results, if they were to be correct, how did pstate end up being the default governor ?