Please change intel_pstate default to disable

This change was made by a bot.

Tested the test kernel at http://people.canonical.com/~apw/lp1188647-saucy/ and verified that:

1) Booting with intel_pstate=enable enables the intel pstate governor, and all the badness that came with it.
2) Booting with no kernel arguments disables the pstate governor and lets me use ondemand again.

This bug was fixed in the package linux - 3.9.0-5.12

---------------
linux (3.9.0-5.12) saucy; urgency=low

  [ Andy Whitcroft ]

  * Revert "HAVE_CPLUS_DEMANGLE=n"
  * SAUCE: intel_pstate -- toggle default to disable
    - LP: #1188647
  * SAUCE: ubuntu: overlayfs -- ovl_path_open should not take path
    reference
    - LP: #1098378
 -- Andy Whitcroft <email address hidden> Wed, 12 Jun 2013 13:28:56 +0100

Seems this is not working well in 3.10 either where it also applies to more systems as well. Pull this change up to the v3.10. Note we are not as yet applying it to 3.11 based kernels to allow testing there.

Andy,
from looking at the amd64 config, that might actually be fallout from the nohz changes in 3.10. Have you tried

CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ_FULL=n

instead?

This bug was fixed in the package linux - 3.10.0-2.11

---------------
linux (3.10.0-2.11) saucy; urgency=low

  [ Andy Whitcroft ]

  * [Config] enforce CONFIG_DEBUG_INFO
  * SAUCE: intel_pstate -- toggle default to disable
    - LP: #1188647
  * [Packaging] add accellerators for binary-udeb
  * SAUCE: ext4: fix ext4_get_group_number() at cluster boundaries
    - LP: #1195710

  [ John Johansen ]

  * SAUCE: (no-up) apparmor: fix apparmor module status for none root users
    - LP: #1199912

  [ Leann Ogasawara ]

  * d-i: Add qlcnic to nic-modules
    - LP: #1196597

  [ Tim Gardner ]

  * [Debian] Prepare to build using arch specific compiler
  * Build armhf using gcc-4.7
 -- Tim Gardner <email address hidden> Thu, 11 Jul 2013 08:56:44 -0600

If possible, I would very much like to try to re-create the problems detailed herein on my computer.
While I have had issues with the driver, I have not experienced the issues of the original post.
I have been testing and giving feedback for the intel pstate driver for over a month.
I agree that is was premature to make it the default cpu scaling driver.
I am not aware of any issues with the proposed patch (not committed yet, as far as I know) of the below referenced bugzilla report.

References:

https://bugzilla.kernel.org/show_bug.cgi?id=59481
http://ubuntuforums.org/showthread.php?t=2151440

I have not tried this in recent Ubuntu yet, but I can tell you that pstate seems to work very well in Debian's 3.10 kernel on my Ivy Bridge laptop. The problem thus might not be caused by intel_pstate itself but by a combination with some other option(s) and/or patch. It seems to increase the frequency much faster than the ondemand governor; but this does not seem to be bad; in any case, my fan is off most of the time.

Maybe this helps you. I can check it on Ubuntu too, but I just wanted to let you know my experience on Debian first.

I switched from Ubuntu 12.04.3 LTS with 3.80 kernel to Manjaro. The reason is Ubuntu enables nvidia optimus technology via the latest 319 drivers. In practice Ubuntu is among the few distros where the current implementation of works well. The frame rates with games go more than twice than with Bumblebee and optirun command. All this is fine if your intention are to use your laptop as a gaming machine. Sadly on my i7 ivybridge laptop, this also meant added heat to the tune of +10C and more at idle as compared to Bumblebee as well as very low battery life, I lost close to one and half hour.

I decided to try out Manjaro as it brings me to Arch minus the headaches. Manjaro implements latest nvidia 325 drivers during install with choice of kernel 3.4, 3.10 and latest 3.11 This also gave me a chance to try out Intel's Pstate driver. In 3.11 it has matured greatly. In practice compared to non Pstate kernel 3.4 the CPU at idle ran around 50C average whereas with 3.4 kernel they would run at 45C going down to 39c sometimes. This was kind of disappointing but I saw the cores getting better utilized and system response snappier than cpu freq ondemand. I then decided to install Intel Thermal Daemon and something wonderful occurred. The idle temps didn't go down but peak temps under full load never ever exceeded 60C with max of 68c under full load. Without the daemon under full load they would touch up to 75, still lower than close to 90c I was getting with Ubuntu and kernel 3.8

The temp average now puts Windows machine to shame, its lower under load and also battery life with TLP is as good as Windows machine. So looks like good things are in store for Linux in future. The kernel 3.11 is a beauty, rock stable and very efficient with far lower memory consumption. Time for Ubuntu to get into action on this.

I recommend switching back to to use intel pstate by default for the 3.11 kernel in Saucy as the overly-high frequency issue seems to be resolved now (from what I recall when I was trying out the 3.10 and 3.11 kernels, this issue was caused by particular settings in the kernel config; changing the settings fixed the issue and the stock Ubuntu 3.11 kernel now has those changed settings).

This is particularly important as the acpi-cpufreq ondemand governor appears to have major issues in 3.11 (at least it does on my laptop - it can't change the cpu frequencies and they remain locked at the lowest setting so system performance is abysmal - see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1233479).

Please enable pstate in Saucy kernel, all other distributions including Fedora, SUSE and ARCH have it enabled with good results.

I was wondering why my system wasn't using pstate until I realized I was looking at the upstream sources... checked out the saucy git tree and saw it was disabled by default, and enabled it and have had good results so far. Maybe it's time to revert this?

Please consider reverting this decision, especially now that Ubuntu has thermald in repos which is taylored for use with intel pstate.

Mateusz - See Colin's response in this thread. https://lists.ubuntu.com/archives/kernel-team/2014-April/041514.html

For the decision to re-enable the intel pstate driver by default or not, the suggestion is to be cautious. The driver keeps changing in rather fundamental ways, such that one can never be sure how it is going to perform. I will attach two graphs to (hopefully) help make my point.

The first graph demonstrates a dramatic difference in CPU frequency scaling response as a function of load between kernel 3.12 and 3.15RC2 at a fixed idle (sleep) / work frequency.

The second graph (to be posted in a moment) demonstrates a dramatic difference in CPU scaling frequency as a function of idle (sleep) /work frequency at a fixed load.

Don't get me wrong here, as I am a proponent of the intel_pstate driver, but I am concerned about how its response to stimulus keeps changing.

Graph 2 of 2. see previous comment.

Just another way of showing the dramatic difference in intel_pstate versions response to loads. The phoronix ffmpg test was one that has been mentioned in upstream tests before.

Note: "nokick" refers to https://bugzilla.kernel.org/show_bug.cgi?id=64271 backported to kernel 3.12.

Interesting graphs. It looks like they got it to use much lower frequencies for that particular load. What I really wonder about though, is whether it actually uses less power or not? According to Matthew Garret, lowering the cpu frequency does not save power since the deep C states save a lot more power, and you spend more time in those when you burn through the work at the higher frequency and get back to sleep asap.

Kernel 3.15 contains some intel_pstate changes that should address the issues I raised in post 16 above.

For Ubuntu one concern is: For the 250 Hz kernel the default sample rate will result in an actual different sample rate, and thus the response curve is a little different than for the 1000 Hz kernel. The desire is to have the default sample rate be 12 milliseconds instead of 10 (3 jiffies for 250 Hertz and 10 jiffies for 1000 Hz). This change is on the to-do list. This is probably a minor issue.

For this change:
"intel_pstate: add sample time scaling" I have a concern (and a ton of evidence to support it) that often, but very dependent on periodic workloads, the deferrable timer is delayed when it is not expected to be delayed, and sometimes by a huge amount (4 seconds). The result can be lower than expected CPU frequencies, because new the scale down code kicks in when it shouldn't.

Enabling intel-pstate on the 3.13 kernel was deemed problematic for several reasons. However, I have backported all of the changes upto 4.2-rc8 to 3.13 and re-enabled the intel-pstate driver for testing. I have performed a boot smoke test with this kernel and I think it needs some deeper testing to see if it resolves your issues.

The kernel packages can be found in:

http://kernel.ubuntu.com/~cking/intel-pstate

Please can you see if these help.

I think we need to know if intel_pstate is more stable in 4.x series,
because the new releases. If it keeps unstable may be disable by
default is the better choice.

2015-08-27 14:33 GMT-03:00 Colin Ian King <email address hidden>:
> Enabling intel-pstate on the 3.13 kernel was deemed problematic for
> several reasons. However, I have backported all of the changes upto
> 4.2-rc8 to 3.13 and re-enabled the intel-pstate driver for testing. I
> have performed a boot smoke test with this kernel and I think it needs
> some deeper testing to see if it resolves your issues.
>
> The kernel packages can be found in:
>
> http://kernel.ubuntu.com/~cking/intel-pstate
>
> Please can you see if these help.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1188647
>
> Title:
> Please change intel_pstate default to disable
>
> Status in linux package in Ubuntu:
> Fix Released
>
> Bug description:
> 3.9 introduced a new default governor on SandyBridge CPUs called
> INTEL_PSTATE which, when built in and enabled (the default), removes
> all other governors (like our usual default, ondemand). 3.10 extended
> this to Ivybridge generation CPUs.
>
> In theory, this isn't an awful thing, as the new Intel pstate governor
> should be higher performance and give better power savings. In
> theory.
>
> In practice, it drives my CPUs to max frequency nearly constantly,
> spins my fans like mad and, somehow, does all of this while also
> eating enough CPU time in kernel threads to make my machine choppy,
> unresponsive, and unable to do simple things like play videos when I
> get off work.
>
> Therefore, I propose that we, for now, toggle intel_pstate to disable
> by default (I am using intel_pstate=disable on my command line right
> now, with great success), so it's still built in, and people can play
> with it, but it's off by default.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 13.10
> Package: linux-image-3.9.0-4-generic 3.9.0-4.9
> ProcVersionSignature: Ubuntu 3.9.0-4.9-generic 3.9.4
> Uname: Linux 3.9.0-4-generic x86_64
> ApportVersion: 2.10.2-0ubuntu1
> Architecture: amd64
> AudioDevicesInUse:
> USER PID ACCESS COMMAND
> /dev/snd/controlC0: adconrad 2574 F.... pulseaudio
> CurrentDmesg:
> [ 30.633035] init: plymouth-stop pre-start process (2079) terminated with status 1
> [ 36.086916] br0: port 1(eth0) entered forwarding state
> Date: Fri Jun 7 08:48:56 2013
> HibernationDevice: RESUME=UUID=73040efa-baec-458a-8307-3bca07b26c3c
> InstallationDate: Installed on 2012-12-09 (179 days ago)
> InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20121209)
> MachineType: LENOVO 4173LPB
> MarkForUpload: True
> ProcFB: 0 inteldrmfb
> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.9.0-4-generic root=UUID=2222aad5-ef31-4428-973f-71740fc7cb6a ro intel_pstate=disable quiet splash vt.handoff=7
> RelatedPackageVersions:
> linux-restricted-modules-3.9.0-4-generic N/A
> linux-backports-modules-3.9.0-4-generic N/A
> linux-firmware 1.109
> SourcePackage: lin...

@Colin:
I am not sure who you are asking to "see if these help". For my part of it, I pretty much only use the most recent RC kernel (well I am still on 4.2RC6), and pretty much only with a version if the intel_pstate driver that includes a proposed patch set that I submitted on 2015.04.11, but that is still on hold. See: http://permalink.gmane.org/gmane.linux.power-management.general/58958

The basic control algorithms of the current version of the intel_pstate driver have been stable for quite sometime now (even though I still have concerns). I do not know what changes had not previously been backported to kernel 3.13, nor what issues people were having, so am unable to comment further.

One problem I have noticed with the pstate driver is that it ignores all of the control knobs. It absolutely refuses to let you limit the range of frequencies it will use. When playing minecraft I find that by default it tends to run full speed and that isn't really needed, so lowering the speed can save power and heat, but the pstate driver refuses to do so.

@Phillip: Tell us more about what you trying to do and how you are doing it.

I assert that the "control knobs" work fine, however, I only use primitives to control it and never any higher level tool.
For example, I would limit the maximum CPU frequency to 0.75 of maximum with:

echo "75" | sudo tee /sys/devices/system/cpu/intel_pstate/max_perf_pct

(If I was in performance mode and not powersave mode, then I would set the min_perf_pct to 75 also, but I myself I wouldn't be in performance mode for this situation.)

That's exactly what I do and it doesn't work. Along with I think it was the cpuX/scaling_max_freq and scaling_governor to powersave. In each case it does not actually have any effect.

When I disable intel_pstate, then the cpuX/ settings work fine.

@Phillip: I would like to get to the root of your issue, but I don't know that this is the place to do it.

What is your processor? Mine is: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
What kernel version do you run? I am running 4.3RC1 with a modified intel_pstate driver.

If I start a CPU burning process on CPU 7 I get:

doug@s15:~/temp$ grep MHz /proc/cpuinfo
cpu MHz : 3699.757
cpu MHz : 3627.640
cpu MHz : 3684.351
cpu MHz : 3800.429
cpu MHz : 3524.710
cpu MHz : 3522.187
cpu MHz : 3540.250
cpu MHz : 3799.898

Then if I set an upper limit:

echo "75" | sudo tee /sys/devices/system/cpu/intel_pstate/max_perf_pct

I get:

doug@s15:~/temp$ grep MHz /proc/cpuinfo
cpu MHz : 2799.953
cpu MHz : 2799.953
cpu MHz : 2799.953
cpu MHz : 2799.953
cpu MHz : 2853.078
cpu MHz : 2799.953
cpu MHz : 2799.953
cpu MHz : 2799.953

as expected.
As a sanity check, my CPU prints a time message occasionally, so we would expect it to have a bigger gap between prints now:

doug@s15:~/c$ taskset -c 7 ./test1
Elapsed: 174.06 s. Delta: 174.06 s. Ave (10): 17.41 s. user cpu: 173.88 s. sys cpu: 0.06 s.
Elapsed: 348.04 s. Delta: 173.98 s. Ave (10): 34.80 s. user cpu: 347.74 s. sys cpu: 0.06 s.
Elapsed: 557.31 s. Delta: 209.27 s. Ave (10): 55.73 s. user cpu: 556.88 s. sys cpu: 0.06 s.
Elapsed: 792.06 s. Delta: 234.75 s. Ave (10): 79.21 s. user cpu: 791.47 s. sys cpu: 0.07 s.

174 / 235 = 74%

@Phillip: By the way, for the previous tests, I didn't go back to a stock kernel because I knew it wouldn't make any difference. However, you would be correct to challenge that assertion, so I re-did everything with my stock kernel:

Linux s15 3.16.0-49-generic #65~14.04.1-Ubuntu SMP Wed Sep 9 10:03:23 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

The results were the same.

I'm posting here because pstate is giving me problems as well, but in the opposite direction. Upon bootup and for several hours thereafter, scaling works correctly. But after a period of time something happens (which is of course not mentioned in any log) and scaling_max_freq is set to scaling_min_freq and cannot be changed at all.

root@ossy:/etc# cd /sys/devices/system/cpu/cpu0/cpufreq
root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# ls
affected_cpus cpuinfo_transition_latency scaling_driver scaling_setspeed
cpuinfo_cur_freq related_cpus scaling_governor
cpuinfo_max_freq scaling_available_governors scaling_max_freq
cpuinfo_min_freq scaling_cur_freq scaling_min_freq
root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_max_freq
1600000
root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# cat cpuinfo_max_freq
3700000
root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# cat cpuinfo_max_freq > scaling_max_freq
root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_max_freq
1600000

root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# echo performance > scaling_governor
root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_governor
performance
root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# cat cpuinfo_max_freq > scaling_max_freq
root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_max_freq
1600000

This happens whether or not I have Enhanced SpeedStep enabled in my BIOS. (This is also not a BIOS limit problem.) Disabling pstate entirely allows me to run at 3.3GHz all the time. Since powerclamp is loaded and thermald is running I'm still protected from overheating situations. Since this is a desktop I don't really care about the power usage but I can see where this would be a bigger problem for laptops.

@mike : This probably isn't the place to look into your issue. Do you have accounts on askubuntu.com or ubuntuforums.org ? Perhaps the issue could be moved there.

There have been issues as the intel_pstate driver has evolved to include control via the methods you are using. What is your processor model? What is your kernel version? And does your issue persist with the latest mainline kernel, 4.10-rc6 (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10-rc6/)?

I had looked at other relevant threads on askubuntu but I figured it was a kernel issue. I'll certainly work within the context of this bug to try to fix if possible. I'm on 4.9.0-15-generic but I just installed 4.10.0-041000rc6.201701291830 and will reply with results (after removing the line from /etc/default/grub to disable pstate). Relevant info from cpuinfo:

vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
stepping : 7
microcode : 0x29
cpu MHz : 3311.061

Threads (among many) that I saw on askubuntu
http://askubuntu.com/questions/296653/ubuntu-13-04-cpu-frequency-scaling-stuck-on-lowest-frequency
http://askubuntu.com/questions/353383/cpu-frequency-scaling-issue-scaling-max-freq-wrong

Wow. I've never seen this before. My scaling_min_freq and scaling_max_freq are now set to... 0!

root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# ls -1 *
affected_cpus
cpuinfo_cur_freq
cpuinfo_max_freq
cpuinfo_min_freq
cpuinfo_transition_latency
related_cpus
scaling_available_governors
scaling_cur_freq
scaling_driver
scaling_governor
scaling_max_freq
scaling_min_freq
scaling_setspeed
root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# cat *
0
1737414
3700000
1600000
4294967295
0
performance powersave
1737414
intel_pstate
performance
0
0
<unsupported>

root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# uname -a
Linux ossy 4.10.0-041000rc6-generic #201701291830 SMP Sun Jan 29 23:32:29 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

And now scaling_max_freq is stuck:

root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# cat cpuinfo_max_freq > scaling_max_freq
root@ossy:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_max_freq
0

Inside of the intel_pstate folder, I can move max_perf_pct up to 44 max, and turn on turbo:

root@ossy:/sys/devices/system/cpu/intel_pstate# ls -1
max_perf_pct
min_perf_pct
no_turbo
num_pstates
turbo_pct
root@ossy:/sys/devices/system/cpu/intel_pstate# cat *
0
0
1
22
19
root@ossy:/sys/devices/system/cpu/intel_pstate# echo 40 > min_perf_pct
root@ossy:/sys/devices/system/cpu/intel_pstate# cat min_perf_pct
0
root@ossy:/sys/devices/system/cpu/intel_pstate# echo 100 > max_perf_pct
root@ossy:/sys/devices/system/cpu/intel_pstate# cat max_perf_pct
44
root@ossy:/sys/devices/system/cpu/intel_pstate# echo 0 > no_turbo
root@ossy:/sys/devices/system/cpu/intel_pstate# cat no_turbo
0
root@ossy:/sys/devices/system/cpu/intel_pstate# echo 100 > max_perf_pct
root@ossy:/sys/devices/system/cpu/intel_pstate# cat max_perf_pct
44

But I'm sure at some point later it will go down again and not go back up until I change things manually (or reboot). Not entirely sure when this happened. I had it running for over 12 hours (including a lot of load with BOINC projects overnight). It wasn't stuck like this in the morning, but at some point today it got into this state. Nothing strange I can see in my system log, except for maybe

[13347.141990] powercap intel-rapl:0: package locked by BIOS, monitoring only

But I don't think my BIOS is limiting anything because when I
echo 1 > /sys/module/processor/parameters/ignore_ppc
it doesn't make a difference, I still can't change any of the values (scaling_max_freq or max_perf_pct) that I want to get my original speed back, only rebooting helps.

Anyway, if you don't think this is the right bug I can open another one or something, but unless you can suggest a patch to try or a setting to change I am probably just going to disable pstate on the GRUB command line and be done with it (and of course ensure thermald and powerclamp are running and my fans are in good shape and as dust-free as can be).

@mike:

> if you don't think this is the right bug I can open another one or something,

This is not the right bug report, and we need to get off it before others start to complain.
However, it isn't time to open a new one yet, in my opinion, because we don't yet know what to file it against.

> but unless you can suggest a patch to try or a setting to change I am
> probably just going to disable pstate on the GRUB command line and be done with it

Well, a lot of people do just that, but then also wonder why issues don't get solved. Issues don't get solved if people don't investigate.

Myself, and without any proof, I suspect thermald is your root issue. Have a look at this bug: https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1656528

By the way, a cool trick for some of the stuff you were listing above is to do this instead:

root@s15:/sys/devices/system/cpu/cpu0/cpufreq# grep . *
affected_cpus:0
cpuinfo_cur_freq:1599768
cpuinfo_max_freq:3800000
cpuinfo_min_freq:1600000
cpuinfo_transition_latency:4294967295
related_cpus:0
scaling_available_governors:performance powersave
scaling_cur_freq:1599768
scaling_driver:intel_pstate
scaling_governor:powersave
scaling_max_freq:3800000
scaling_min_freq:1600000
scaling_setspeed:<unsupported>

Ooh thanks for the grep trick I knew there was a better way. thermald may have something to do with it but I'm not getting the syslog spamming like that bug report, though I do have a couple of those entries listed. I will stop posting to this bug though.