Unable to override cpufreq/intel pstate horrific throttling of CPU.

RoflCopter4 · 2017-10-19 16:09:59

I'm not entirely sure this belong in the category, but it seems like such a simple matter that it's probably best to look here first. I absolutely hate actually asking questions like this on a forum because I feel like I'm just wasting everyone's time, but in this case I have searched high and low for an answer for days and not found one, so I don't know what else to do.

In my BIOS, my cpu is overclocked to 4.1GHz on all cores, with anything related to changing it dynamically (turbo, speedstep, etc) disabled. There should be no way in which anything should change the frequency from 4.1GHz. In Windows this works flawlessly. But in ArchLinux, this setting is completely, 100% ignored. In fact, any and all BIOS settings seem to be ignored. According to every test program I've tried, of which the best are i7z and turbostat, two threads are allowed a maximum of 3.8GHz, with the remaining 10 between 3.4 and 3.6. This is close to, but not quite the same as, the stock, unoverclocked behavior of the i7 6800k. Evidently BIOS settings mean nothing.

I've tried several things to fix this. I have changed all of the governors to performance, which accomplished nothing whatsoever. Intel doesn't use the cpufreq governor for anything, and only performance and powersave are even possible. I have tried to change the pstate settings, but the only available options seem to be to force it to use some percentage of the predetermied maximum frequency. Attempts to change that maximum frequency result in either nothing or outright crashes. Editing the files directly results has the same results. I tried blacklisting the cpufreq module in modprobe.d, which did nothing. It was loaded anyway. I tried looking for kernel settings that might help but found none. There seem to be no settings for this directly. I am baffled.

I just want to point out that I had a similar problem in FreeBSD (which I installed in a stupified rage a few days ago after giving up on ever fixing this problem), which also employs cpufreq. However, in FreeBSD the solution was extraordinarily easy. A mere single line added to rc.conf completely and utterly overrode the behavior of cpufreq and forced the maximum frequency at all times. The only thing that keeps me from throwing away linux forever is the fact that BSD is terrible, FreeBSD has almost no bluetooth support, awful video support, and general usability issues.

That aside, the fact that it was so easy in BSD tells me that there must be something somewhere that I'm overlooking. Surely it must be possible to simply disable the stupid throttling altogether? I don't care in the least about power savings. I would not have purchased the 6800k if I did. What am I doing wrong?

cfr · 2017-10-19 17:13:46

https://wiki.archlinux.org/index.php/CP … cy_scaling

progandy · 2017-10-19 17:16:20

(Did you read the wiki page? There seems to be a note in a blue box talking about disabling intel_pstate?
https://wiki.archlinux.org/index.php/CP … ncy_driver)

And the kernel documentation for intel_pstate:
https://www.kernel.org/doc/html/v4.13/a … state.html

Last edited by progandy (2017-10-19 17:17:00)

RoflCopter4 · 2017-10-19 18:23:32

cfr wrote:

https://wiki.archlinux.org/index.php/CP … cy_scaling

I actually find this post to be more than a little bit insulting.

progandy wrote:

(Did you read the wiki page? There seems to be a note in a blue box talking about disabling intel_pstate?
https://wiki.archlinux.org/index.php/CP … ncy_driver)
And the kernel documentation for intel_pstate:
https://www.kernel.org/doc/html/v4.13/a … state.html

I read both documents and tried pretty much every combination of settings listed that I could think of. I can't fathom why anyone would make a forum account and post a question without having done exhausted every other available option first.

Nothing works. Nothing works AT ALL. No matter the settings, no matter what driver, no matter what kernel paramaters, no matter what config options, no matter what defaults, the cpu frequencies are locked at exactly the same values.

dockland · 2017-10-19 18:34:34

What kernel parameter did you use to disable intel pstate?

E: Typo

Last edited by dockland (2017-10-19 18:34:54)

loqs · 2017-10-19 18:35:23

When you disabled the intel_pstate driver what command and output did you use to verify it was disabled?
What scaling governors were then available again please provide the command used and its output.

seth · 2017-10-19 21:07:28

1. instead of ranting, please always provide actual commands you issued, configs you made and outputs and read-outs from the /sys/devices/system/cpu/** files (notably those about the cpu frequency) - a higher signal to noise ratio will lead to more and better replies.
2. "blacklisting" does not prevent indirect loading, the kernel parameter wiki page has details on this and how to prevent loading nevertheless.
3. "I can't fathom why anyone would make a forum account and post a question without having done exhausted every other available option first." - Welcome to the archlinux forums. If you stay around, you'll figure ... not "why", but "that".

RoflCopter4 · 2017-10-19 21:35:46

seth wrote:

1. instead of ranting, please always provide actual commands you issued, configs you made and outputs and read-outs from the /sys/devices/system/cpu/** files (notably those about the cpu frequency) - a higher signal to noise ratio will lead to more and better replies.
2. "blacklisting" does not prevent indirect loading, the kernel parameter wiki page has details on this and how to prevent loading nevertheless.
3. "I can't fathom why anyone would make a forum account and post a question without having done exhausted every other available option first." - Welcome to the archlinux forums. If you stay around, you'll figure ... not "why", but "that".

Agreed there. I actually wrote a reply last night but had the wisdom to sleep on it. I should really learn to take a deep breath sometimes before I go off and just sound incoherent.

In response to previous posts, I have tried passing quite a few kernel paramaters at this point. I tried "intel_pstate=disable", which just disabled any ability to get diagnostics on the CPU. "intel_pstate=off" had similar results. Setting it to passive allowed cpupower to think it was accomplishing something, but in reality everything it did (ie trying to change the max cpu switching frequency) was ignored entirely. The pstate_frequency program only seems to have the ability to change the range in which the cpu frequency will operate, but not the actual bounds of that range, which is what I want. No diagnostics were available from anything but i7z, which reported no change. No governors were available. No configuration was available. Disabling that driver disabled everything.

There are quite a fair few files in /sys/devices/system/cpu/, and quite a few cores too. In short, the maximum frequency that they all seem to allow is 3.8GHz, but in practice only two of the twelve logical threads take that value and the rest the lower value of 3.6GHz. Nothing I have tried has persuaded the driver to sway from these values in any way whatsoever. I'm not sure what diagnostics to provide, because they have all seemed rather useless to me. Everything is ignored. My basic confusion here is why on earth my clearly stated BIOS settings are not taking priority. Windows makes no attempt to change them at all, and as mentioned FreeBSD easily allowed them to take priority by adding one line stating as such to powerd in rc.conf. I figured that there simply must be something like that that I'm missing here. I shouldn't have to be messing about with kernal paramaters for something that every other operating system I've tried has been able to do with either no or very minimal effort. Is there genuinely no systemd equivalent to powerd that could be passed one simple paramater to change how it operates? I thought systemd was meant to be more convenient.

I incidentally also tried the hack the wiki suggests to get around incidental loading, to no effect.

If I have to mess around with the kernel then I suppose I have to, but I was hoping to avoid the need for diagnostics and potentially hacky solutions.

Last edited by RoflCopter4 (2017-10-19 21:38:03)

cfr · 2017-10-19 22:15:13

RoflCopter4 wrote:

cfr wrote:
https://wiki.archlinux.org/index.php/CP … cy_scaling
I actually find this post to be more than a little bit insulting.
.

Why? You said you'd searched and found nothing. You didn't say you'd found X, Y and Z, tried X by doing A with result D, tried Y by doing B with result E and determined that Z was inapplicable due to F.

Even aside from the fact that people search without posting all the time, searching isn't always successful, even when there's something to find. You search for too general a term or too a specific one, or you use the site's search which can be rather fussy, or you have been trouble-shooting for hours and are so exhausted you just don't see the connection between the problem and what you're reading.

In any of those cases, I'm very grateful for a pointer. And if I'd already tried things from the wiki, I'd explain what I'd tried and what happened. I'd post output, hardware information, logs - whatever I can find which might give somebody a clue what is happening or not happening.

We don't know what you've read, what you've typed or what your computer has told you. If you can't figure out the problem with the computer right there, how can you expect people to figure it out without your advantage?

If you've really tried everything and nothing works as it should, that's obviously very unusual. The wiki reflects not just what should work in theory, but what is known and found to work in practice. If your case doesn't fit, there is something odd going on: either something hardware specific or a configuration quirk or a bug or user error. Right now, we have no idea which.

Did you do anything besides disabling intel_pstate? Did you try to enable an alternative governor or modules?

Last edited by cfr (2017-10-19 22:25:35)

RoflCopter4 · 2017-10-19 22:31:56

cfr wrote:

RoflCopter4 wrote:
cfr wrote:
https://wiki.archlinux.org/index.php/CP … cy_scaling
I actually find this post to be more than a little bit insulting.
.
Why? You said you'd searched and found nothing. You didn't say you'd found X, Y and Z, tried X by doing A with result D, tried Y by doing B with result E and determined that Z was inapplicable due to F.
Even aside from the fact that people search without posting all the time, searching isn't always successful, even when there's something to find. You search for too general a term or too a specific one, or you use the site's search which can be rather fussy, or you have been trouble-shooting for hours and are so exhausted you just don't see the connection between the problem and what you're reading.
In any of those cases, I'm very grateful for a pointer. And if I'd already tried things from the wiki, I'd explain what I'd tried and what happened. I'd post output, hardware information, logs - whatever I can find which might give somebody a clue what is happening or not happening.
We don't know what you've read, what you've typed or what your computer has told you. If you can't figure out the problem with the computer right there, how can you expect people to figure it out without your advantage?
If you've really tried everything and nothing works as it should, that's obviously very unusual. The wiki reflects not just what should work in theory, but what is known and found to work in practice. If your case doesn't fit, there is something odd going on: either something hardware specific or a configuration quirk or a bug or user error. Right now, we have no idea which.
Did you do anything besides disabling intel_pstate? Did you load an alternative driver? Otherwise, as the wiki explains, you'll get no driver at all.

I found it insulting because:

1. I had, at the time of writing, not slept in over 48 hours and was exhausted, and

2. While I appreciate pointers, such an obvious one as that should, in my opinion, at least be accompanied by some kind of message or another. I interpreted it as you simply copy pasting a link and telling me to get lost.

In other words I overreacted. I'm sorry.

From reading the intel driver documentation I gathered that it couldn't actually be replaced. It can at best masquerade as a dumber driver. I tried that too by setting it to "passive" mode. Again, no difference. I tried editing every file in /sys/devices/system/cpu/cpufreq to no results whatsoever. I tried various other kernel settings for the intel_pstate option mentioned in their documentation to no results. I tried changing every single setting in my BIOS, one at a time, to no results. I tried several mentioned pieces of software (ie cpupower and pstate-frequency, to no results. I even tried setting my "overclock" in BIOS to a ridiculously low value of 2GHz to see if it, too, would be ignored. It was. This is the source of my frustration and the reason I did not provide much in the way of diagnostics. I assumed that there was a dead simple setting I did not know of that would allow the clearly defined BIOS settings to apply in the operating system. As I have said twice, FreeBSD, which was in every other way a nightmere to configure, had such an option. Surely, I thought, one must exist for linux.

jasonwryan · 2017-10-19 22:39:30

loqs wrote:

When you disabled the intel_pstate driver what command and output did you use to verify it was disabled?
What scaling governors were then available again please provide the command used and its output.

Ranting, and rambling posts about what you think is happening may be interesting to you, but offer the community little in the way of actual information to analyse. You have been asked for output, please provide it.

RoflCopter4 · 2017-10-20 00:14:32

Ask 4 times and ye shall receive. I put all of this info together the dumbest way possible (ie copy pasting terminal output and simply `cat *`, etc) so I hope at least something is useful.

intel_pstate=per_cpu_perf_limits

OUTPUT FROM `pstate-frequency`

pstate-frequency version 3.8.0
    pstate::CPU_DRIVER   -> intel_pstate
    pstate::CPU_GOVERNOR -> performance
    pstate::TURBO        -> 0 [ON]
    pstate::CPU_MIN      -> 31% [1200000KHz]
    pstate::CPU_MAX      -> 100% [3800000KHz]
pstate-frequency version 3.8.0
    pstate::CPU[0]   -> 3399.977MHz
    pstate::CPU[1]   -> 3399.977MHz
    pstate::CPU[2]   -> 3399.977MHz
    pstate::CPU[3]   -> 3399.977MHz
    pstate::CPU[4]   -> 3399.977MHz
    pstate::CPU[5]   -> 3399.977MHz
    pstate::CPU[6]   -> 3399.977MHz
    pstate::CPU[7]   -> 3399.977MHz
    pstate::CPU[8]   -> 3399.977MHz
    pstate::CPU[9]   -> 3399.977MHz
    pstate::CPU[10]   -> 3399.977MHz
    pstate::CPU[11]   -> 3399.977MHz

---------------------------------------------------------------------------------------------------------------------
SNAPSHOT FROM i7Z:

Socket-0 [num of cpus 6 physical 6 logical 12] 5,
Socket-1 [num of cpus 0 physical 0 logical 0] 
GUI has been Turned ON
physical cores=6, logical cores=12, max online cores ever=6]
  TURBO ENABLED on 6 Cores, Hyper Threading ON
  Max Frequency without considering Turbo 3498.97 MHz (99.97 x [35])
  Max TURBO Multiplier (if Enabled) with 1/2/3/4/5/6 Cores is  38x/38x/41x/41x/41x/41x
  Real Current Frequency 3735.83 MHz [99.97 x 37.37] (Max of below)
        Core [core-id]  :Actual Freq (Mult.)      C0%   Halt(C1)%  C3 %   C6 %  Temp      VCore
        Core 1 [0]:       3530.75 (35.32x)      2.48    45.4    1.41    50.6    22      1.1807
        Core 2 [1]:       3514.52 (35.16x)      2.78    41.6    8.49      47    23      1.1937
        Core 3 [2]:       3568.20 (35.69x)      4.93    45.2    1.49    48.1    23      1.1936
        Core 4 [3]:       3735.83 (37.37x)      2.25    65.9    2.42    29.3    23      1.2314
        Core 5 [4]:       3547.09 (35.48x)      1.47    59.9    1.84    36.7    24      1.2030
        Core 6 [5]:       3597.89 (35.99x)      2.69    22.9    1.15    73.1    22      1.1932

---------------------------------------------------------------------------------------------------------------------
OUTPUT FROM `cpupower cpufreq-info`

analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 1.20 GHz - 3.80 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 1.20 GHz and 3.80 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 3.34 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

---------------------------------------------------------------------------------------------------------------------
VALUES OF ALL FILES IN /sys/devices/system/cpu/cpufreq/cpu0

---  OUTPUT FROM affected_cpus  ---
0

---  OUTPUT FROM cpuinfo_max_freq  ---
3800000

---  OUTPUT FROM cpuinfo_min_freq  ---
1200000

---  OUTPUT FROM cpuinfo_transition_latency  ---
4294967295

---  OUTPUT FROM related_cpus  ---
0

---  OUTPUT FROM scaling_available_governors  ---
performance powersave

---  OUTPUT FROM scaling_cur_freq  ---
3110123

---  OUTPUT FROM scaling_driver  ---
intel_pstate

---  OUTPUT FROM scaling_governor  ---
performance

---  OUTPUT FROM scaling_max_freq  ---
3800000

---  OUTPUT FROM scaling_min_freq  ---
1200000

---  OUTPUT FROM scaling_setspeed  ---
<unsupported>

intel_pstate=active

OUTPUT FROM `pstate-frequency`

pstate-frequency version 3.8.0
    pstate::CPU_DRIVER   -> intel_pstate
    pstate::CPU_GOVERNOR -> performance
    pstate::TURBO        -> 0 [ON]
    pstate::CPU_MIN      -> 99% [3762000KHz]
    pstate::CPU_MAX      -> 100% [3800000KHz]
pstate-frequency version 3.8.0
    pstate::CPU[0]   -> 3400.360MHz
    pstate::CPU[1]   -> 3400.360MHz
    pstate::CPU[2]   -> 3400.360MHz
    pstate::CPU[3]   -> 3400.360MHz
    pstate::CPU[4]   -> 3400.360MHz
    pstate::CPU[5]   -> 3400.360MHz
    pstate::CPU[6]   -> 3400.360MHz
    pstate::CPU[7]   -> 3400.360MHz
    pstate::CPU[8]   -> 3400.360MHz
    pstate::CPU[9]   -> 3400.360MHz
    pstate::CPU[10]   -> 3400.360MHz
    pstate::CPU[11]   -> 3400.360MHz

---------------------------------------------------------------------------------------------------------------------
SNAPSHOT FROM i7Z:

Socket-0 [num of cpus 6 physical 6 logical 12] 5,
Socket-1 [num of cpus 0 physical 0 logical 0] 
GUI has been Turned ON
True Frequency (without accounting Turbo) 3400 MHz
  CPU Multiplier 34x || Bus clock frequency (BCLK) 100.00 MHz

Socket [0] - [physical cores=6, logical cores=12, max online cores ever=6]
  TURBO ENABLED on 6 Cores, Hyper Threading ON
  Max Frequency without considering Turbo 3500.00 MHz (100.00 x [35])
  Max TURBO Multiplier (if Enabled) with 1/2/3/4/5/6 Cores is  38x/38x/41x/41x/41x/41x
  Real Current Frequency 3825.86 MHz [100.00 x 38.26] (Max of below)
        Core [core-id]  :Actual Freq (Mult.)      C0%   Halt(C1)%  C3 %   C6 %  Temp      VCore
        Core 1 [0]:       3600.22 (36.00x)         1    5.78       0    93.9    21      1.1807
        Core 2 [1]:       3599.77 (36.00x)         1    49.2       0    50.7    22      1.1937
        Core 3 [2]:       3599.10 (35.99x)         1    3.44       0    96.3    21      1.1936
        Core 4 [3]:       3825.86 (38.26x)         1     100       0       0    22      1.2314
        Core 5 [4]:       3601.15 (36.01x)         1     100       0       0    24      1.2030
        Core 6 [5]:       3548.15 (35.48x)         0    2.23       0    97.8    22      1.1932

---------------------------------------------------------------------------------------------------------------------
OUTPUT FROM `cpupower cpufreq-info`

analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 1.20 GHz - 3.80 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 1.20 GHz and 3.80 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 2.38 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

---------------------------------------------------------------------------------------------------------------------
VALUES OF ALL FILES IN /sys/devices/system/cpu/cpufreq/cpu0

---  OUTPUT FROM affected_cpus  ---
0

---  OUTPUT FROM cpuinfo_max_freq  ---
3800000

---  OUTPUT FROM cpuinfo_min_freq  ---
1200000

---  OUTPUT FROM cpuinfo_transition_latency  ---
4294967295

---  OUTPUT FROM related_cpus  ---
0

---  OUTPUT FROM scaling_available_governors  ---
performance powersave

---  OUTPUT FROM scaling_cur_freq  ---
1836789

---  OUTPUT FROM scaling_driver  ---
intel_pstate

---  OUTPUT FROM scaling_governor  ---
performance

---  OUTPUT FROM scaling_max_freq  ---
3800000

---  OUTPUT FROM scaling_min_freq  ---
1200000

---  OUTPUT FROM scaling_setspeed  ---
<unsupported>

Note the essentially identical output. Waste of time. The difference in the pstate::CPU_MIN value in the first output is my fault, I forgot to manually increase that to 99% like I did with all the others.

intel_pstate=passive

OUTPUT FROM `pstate-frequency`

pstate-frequency version 3.8.0
    pstate::CPU_DRIVER   -> intel_cpufreq
    pstate::CPU_GOVERNOR -> performance
    pstate::TURBO        -> 0 [ON]
    pstate::CPU_MIN      -> 99% [3762000KHz]
    pstate::CPU_MAX      -> 100% [3800000KHz]
pstate-frequency version 3.8.0
    pstate::CPU[0]   -> 3399.621MHz
    pstate::CPU[1]   -> 3399.621MHz
    pstate::CPU[2]   -> 3399.621MHz
    pstate::CPU[3]   -> 3399.621MHz
    pstate::CPU[4]   -> 3399.621MHz
    pstate::CPU[5]   -> 3399.621MHz
    pstate::CPU[6]   -> 3399.621MHz
    pstate::CPU[7]   -> 3399.621MHz
    pstate::CPU[8]   -> 3399.621MHz
    pstate::CPU[9]   -> 3399.621MHz
    pstate::CPU[10]   -> 3399.621MHz
    pstate::CPU[11]   -> 3399.621MHz

---------------------------------------------------------------------------------------------------------------------
SNAPSHOT FROM i7Z:

Socket-0 [num of cpus 6 physical 6 logical 12] 5,
Socket-1 [num of cpus 0 physical 0 logical 0] 
GUI has been Turned ON
True Frequency (without accounting Turbo) 3399 MHz
  CPU Multiplier 34x || Bus clock frequency (BCLK) 99.97 MHz

Socket [0] - [physical cores=6, logical cores=12, max online cores ever=6]
  TURBO ENABLED on 6 Cores, Hyper Threading ON
  Max Frequency without considering Turbo 3498.97 MHz (99.97 x [35])
  Max TURBO Multiplier (if Enabled) with 1/2/3/4/5/6 Cores is  38x/38x/41x/41x/41x/41x
  Real Current Frequency 3854.21 MHz [99.97 x 38.55] (Max of below)
        Core [core-id]  :Actual Freq (Mult.)      C0%   Halt(C1)%  C3 %   C6 %  Temp      VCore
        Core 1 [0]:       3600.06 (36.01x)         1    6.51       0    93.2    21      1.1807
        Core 2 [1]:       3565.15 (35.66x)         1    28.1       0    71.9    21      1.1937
        Core 3 [2]:       3599.40 (36.00x)         1    0.504      0    99.4    21      1.1936
        Core 4 [3]:       3805.48 (38.07x)         1    99.9       0       0    27      1.2314
        Core 5 [4]:       3609.13 (36.10x)         1     100       0       0    23      1.2030
        Core 6 [5]:       3854.21 (38.55x)         0     100       0       0    23      1.1932

---------------------------------------------------------------------------------------------------------------------
OUTPUT FROM `cpupower cpufreq-info`

analyzing CPU 0:
  driver: intel_cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 20.0 us
  hardware limits: 1.20 GHz - 3.80 GHz
  available cpufreq governors: performance schedutil
  current policy: frequency should be within 3.76 GHz and 3.80 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 2.84 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

---------------------------------------------------------------------------------------------------------------------
VALUES OF ALL FILES IN /sys/devices/system/cpu/cpufreq/cpu0

---  OUTPUT FROM affected_cpus  ---
0

---  OUTPUT FROM cpuinfo_max_freq  ---
3800000

---  OUTPUT FROM cpuinfo_min_freq  ---
1200000

---  OUTPUT FROM cpuinfo_transition_latency  ---
20000

---  OUTPUT FROM related_cpus  ---
0

---  OUTPUT FROM scaling_available_governors  ---
performance schedutil 

---  OUTPUT FROM scaling_cur_freq  ---
2124494

---  OUTPUT FROM scaling_driver  ---
intel_cpufreq

---  OUTPUT FROM scaling_governor  ---
performance

---  OUTPUT FROM scaling_max_freq  ---
3800000

---  OUTPUT FROM scaling_min_freq  ---
3762000

---  OUTPUT FROM scaling_setspeed  ---
<unsupported>

intel_pstate=disable
options processor ignore_ppc=1 (in modeprobe.d)

OUTPUT FROM `pstate-frequency`

pstate-frequency version 3.8.0
    pstate::CPU_DRIVER   -> acpi-cpufreq
    pstate::CPU_GOVERNOR -> userspace
    pstate::TURBO        -> 1 [ON]
    pstate::CPU_MIN      -> 94% [3200000KHz]
    pstate::CPU_MAX      -> 100% [3401000KHz]
pstate-frequency version 3.8.0
    pstate::CPU[0]   -> 3399.986MHz
    pstate::CPU[1]   -> 3399.986MHz
    pstate::CPU[2]   -> 3399.986MHz
    pstate::CPU[3]   -> 3399.986MHz
    pstate::CPU[4]   -> 3399.986MHz
    pstate::CPU[5]   -> 3399.986MHz
    pstate::CPU[6]   -> 3399.986MHz
    pstate::CPU[7]   -> 3399.986MHz
    pstate::CPU[8]   -> 3399.986MHz
    pstate::CPU[9]   -> 3399.986MHz
    pstate::CPU[10]   -> 3399.986MHz
    pstate::CPU[11]   -> 3399.986MHz

---------------------------------------------------------------------------------------------------------------------
SNAPSHOT FROM i7Z:

True Frequency (without accounting Turbo) 3400 MHz
  CPU Multiplier 34x || Bus clock frequency (BCLK) 100.00 MHz

Socket [0] - [physical cores=6, logical cores=12, max online cores ever=6]
  TURBO ENABLED on 6 Cores, Hyper Threading ON
  Max Frequency without considering Turbo 3500.00 MHz (100.00 x [35])
  Max TURBO Multiplier (if Enabled) with 1/2/3/4/5/6 Cores is  38x/38x/41x/41x/41x/41x
  Real Current Frequency 3799.22 MHz [100.00 x 37.99] (Max of below)
        Core [core-id]  :Actual Freq (Mult.)      C0%   Halt(C1)%  C3 %   C6 %  Temp      VCore
        Core 1 [0]:       3599.56 (36.00x)      1.71    13.3       0    84.9    21      1.1807
        Core 2 [1]:       3600.37 (36.00x)       1.1    94.7       0    4.13    22      1.1937
        Core 3 [2]:       3598.93 (35.99x)         1    53.4       0    46.4    20      1.1936
        Core 4 [3]:       3799.22 (37.99x)       1.9    78.4       0    19.5    22      1.2314
        Core 5 [4]:       3599.82 (36.00x)      1.03    14.1       0    84.8    21      1.2030
        Core 6 [5]:       3598.98 (35.99x)      1.64      14       0    84.2    21      1.1932

---------------------------------------------------------------------------------------------------------------------
OUTPUT FROM `cpupower cpufreq-info`

analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us
  hardware limits: 1.20 GHz - 3.40 GHz
  available frequency steps:  3.40 GHz, 3.40 GHz, 3.20 GHz, 3.10 GHz, 2.90 GHz, 2.80 GHz, 2.60 GHz, 2.50 GHz, 2.30 GHz, 2.10 GHz, 2.00 GHz, 1.80 GHz, 1.70 GHz, 1.50 GHz, 1.40 GHz, 1.20 GHz
  available cpufreq governors: userspace performance schedutil
  current policy: frequency should be within 3.20 GHz and 3.40 GHz.
                  The governor "userspace" may decide which speed to use
                  within this range.
  current CPU frequency: 3.40 GHz (asserted by call to hardware)
  boost state support:
    Supported: yes
    Active: yes

---------------------------------------------------------------------------------------------------------------------
VALUES OF ALL FILES IN /sys/devices/system/cpu/cpufreq/cpu0

---  OUTPUT FROM affected_cpus  ---
0

---  OUTPUT FROM bios_limit  ---
3401000

---  OUTPUT FROM cpuinfo_cur_freq  ---
3401000

---  OUTPUT FROM cpuinfo_max_freq  ---
3401000

---  OUTPUT FROM cpuinfo_min_freq  ---
1200000

---  OUTPUT FROM cpuinfo_transition_latency  ---
10000

---  OUTPUT FROM freqdomain_cpus  ---
0

---  OUTPUT FROM related_cpus  ---
0

---  OUTPUT FROM scaling_available_frequencies  ---
3401000 3400000 3200000 3100000 2900000 2800000 2600000 2500000 2300000 2100000 2000000 1800000 1700000 1500000 1400000 1200000 

---  OUTPUT FROM scaling_available_governors  ---
performance schedutil 

---  OUTPUT FROM scaling_cur_freq  ---
2558066

---  OUTPUT FROM scaling_driver  ---
acpi-cpufreq

---  OUTPUT FROM scaling_governor  ---
performance

---  OUTPUT FROM scaling_max_freq  ---
3401000

---  OUTPUT FROM scaling_min_freq  ---
3366990

---  OUTPUT FROM scaling_setspeed  ---
<unsupported>

---  OUTPUT FROM stats  ---

---  OUTPUT FROM affected_cpus  ---
0

---  OUTPUT FROM bios_limit  ---
3401000

---  OUTPUT FROM cpuinfo_cur_freq  ---
3401000

---  OUTPUT FROM cpuinfo_max_freq  ---
3401000

---  OUTPUT FROM cpuinfo_min_freq  ---
1200000

---  OUTPUT FROM cpuinfo_transition_latency  ---
10000

---  OUTPUT FROM freqdomain_cpus  ---
0

---  OUTPUT FROM related_cpus  ---
0

---  OUTPUT FROM scaling_available_frequencies  ---
3401000 3400000 3200000 3100000 2900000 2800000 2600000 2500000 2300000 2100000 2000000 1800000 1700000 1500000 1400000 1200000 

---  OUTPUT FROM scaling_available_governors  ---
userspace performance schedutil 

---  OUTPUT FROM scaling_cur_freq  ---
3105629

---  OUTPUT FROM scaling_driver  ---
acpi-cpufreq

---  OUTPUT FROM scaling_governor  ---
userspace

---  OUTPUT FROM scaling_max_freq  ---
3401000

---  OUTPUT FROM scaling_min_freq  ---
3200000

---  OUTPUT FROM scaling_setspeed  ---
3401000

The last output is the only particularly interesting one. With the intel driver disabled it's clear now that the linux cpufreq driver is indeed taking charge, and doing a damn poor job of it. However, it is also apparent that it is limited to the listed frequencies and absolutely refuses to allow any other to be added or used. There is of course a bios limit file there, which makes absolutely no sense since in BIOS I have set the frequencies to be 4.1GHz accross the board. Even after implementing the hack referenced in the wiki to ignore this value, it is not being ignored. Why on earth the kernel won't simply listen to the BIOS settings is quite beyond my understanding. Again, I hope something here is somewhat useful, because I'm running short of ideas.

V1del · 2017-10-20 00:38:21

Also a bit more accurate analysis would be useful, are you simply hanging yourself up on these numbers? The driver will clock down to a certain degree while idling, because it simply doesn't make sense to run it at full speed if there's nothing to do. There are quite a few occasions where intel engineers mention that the notion of having a processor run at a single clock rate all the time is bogus and is not a realistic metric in any case. Modern intels are doing internal scaling and scheduling and the intel_pstate driver has been developed to more accurately represent that fact. Have you actually verified via runtime of some task that you are getting these higher resp. more interestingly the lower clock rates? Maybe the Windows and BSD implementation after adjustment simply show you the value they get from your firmware while the processor does not actually run at that frequency.

For comparisons sake, here's a run of intel_pstate with the performance governor set. You can guess when I was actually running a task

CPU     Avg_MHz Bzy_MHz TSC_MHz
-       170     4265    4008
0       166     3688    4008
4       202     4323    4008
1       156     4372    4008
5       153     4379    4008
2       121     4326    4008
6       179     4445    4008
3       195     4384    4008
7       188     4290    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       103     4075    4008
0       130     3661    4008
4       59      4176    4008
1       106     4219    4008
5       55      4245    4008
2       54      4017    4008
6       218     4215    4008
3       89      4212    4008
7       116     4011    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       81      4167    4008
0       71      3370    4008
4       35      4143    4008
1       81      4290    4008
5       257     4284    4008
2       44      4206    4008
6       45      4434    4008
3       32      4373    4008
7       84      4330    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       173     4311    4008
0       305     3958    4008
4       156     4420    4008
1       163     4371    4008
5       98      4444    4008
2       234     4483    4008
6       84      4437    4008
3       212     4371    4008
7       133     4436    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       53      4110    4008
0       42      3093    4008
4       180     4262    4008
1       88      4185    4008
5       15      4237    4008
2       7       3771    4008
6       11      3855    4008
3       16      4320    4008
7       65      4508    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       122     4342    4008
0       215     4166    4008
4       89      4193    4008
1       93      4265    4008
5       117     4454    4008
2       87      4334    4008
6       59      4496    4008
3       162     4419    4008
7       151     4527    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       104     4275    4008
0       234     4207    4008
4       41      4366    4008
1       243     4288    4008
5       42      4445    4008
2       72      4270    4008
6       55      4193    4008
3       61      4258    4008
7       87      4373    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       132     4537    4008
0       333     4494    4008
4       88      4531    4008
1       40      4502    4008
5       143     4585    4008
2       58      4573    4008
6       40      4366    4008
3       39      4477    4008
7       316     4592    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       72      4181    4008
0       125     3981    4008
4       158     4249    4008
1       22      4086    4008
5       45      4100    4008
2       22      4167    4008
6       105     4187    4008
3       42      4418    4008
7       55      4408    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       100     4178    4008
0       180     3662    4008
4       89      4473    4008
1       43      4239    4008
5       68      4383    4008
2       67      4441    4008
6       210     4247    4008
3       62      4489    4008
7       81      4391    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       188     4212    4008
0       348     3483    4008
4       360     4524    4008
1       110     4452    4008
5       110     4440    4008
2       130     4477    4008
6       107     4507    4008
3       230     4497    4008
7       108     4510    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       227     4170    4008
0       352     3137    4008
4       390     4582    4008
1       68      4375    4008
5       128     4502    4008
2       110     4274    4008
6       322     4583    4008
3       192     4527    4008
7       254     4551    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       723     4600    4008
0       229     4600    4008
4       708     4600    4008
1       2058    4600    4008
5       141     4600    4008
2       1901    4600    4008
6       185     4600    4008
3       236     4600    4008
7       327     4600    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       724     4600    4008
0       531     4600    4008
4       94      4600    4008
1       181     4600    4008
5       158     4600    4008
2       4600    4600    4008
6       36      4600    4008
3       103     4600    4008
7       92      4600    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       675     4600    4008
0       180     4600    4008
4       85      4600    4008
1       102     4600    4008
5       169     4600    4008
2       4600    4600    4008
6       74      4600    4008
3       85      4600    4008
7       108     4600    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       752     4600    4008
0       227     4600    4008
4       178     4600    4008
1       153     4600    4008
5       160     4600    4008
2       4600    4600    4008
6       142     4600    4008
3       303     4600    4008
7       255     4600    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       746     4600    4008
0       282     4600    4008
4       268     4600    4008
1       162     4600    4008
5       124     4600    4008
2       4600    4600    4008
6       176     4600    4008
3       159     4600    4008
7       197     4600    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       648     4600    4008
0       309     4600    4008
4       55      4600    4008
1       54      4600    4008
5       25      4600    4008
2       4600    4600    4008
6       25      4600    4008
3       38      4600    4008
7       75      4600    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       650     4600    4008
0       96      4600    4008
4       318     4600    4008
1       21      4600    4008
5       51      4600    4008
2       4600    4600    4008
6       15      4600    4008
3       32      4601    4008
7       68      4600    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       660     4600    4008
0       90      4600    4008
4       42      4600    4008
1       37      4600    4008
5       281     4600    4008
2       4600    4600    4008
6       67      4600    4008
3       82      4600    4008
7       83      4600    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       633     4600    4008
0       37      4600    4008
4       49      4600    4008
1       10      4601    4008
5       161     4600    4008
2       4600    4600    4008
6       20      4600    4008
3       131     4600    4008
7       55      4600    4008
CPU     Avg_MHz Bzy_MHz TSC_MHz
-       368     4558    4008
0       45      3683    4008
4       24      4394    4008
1       122     4523    4008
5       282     4446    4008
2       2350    4599    4008
6       35      4523    4008
3       26      4441    4008
7       63      4566    4008

RoflCopter4 · 2017-10-20 00:58:49

It's always somewhat difficult to know for sure because modern CPU's will generally always mess about with their frequencies, as you said, but it also seems possible to disable this if you jump through enough hoops. In Windows, if I go out of my way to specify that this should never happen in BIOS, it is reflected as such in all monitoring programs I've tried. Likewise in BSD. I have certainly tested the results under load and they stabalize at exactly the frequencies I mentioned, either 3.8GHz or 3.6GHz on the button (under Prime95, ie the maximum load that could possibly exist). The only kind of evidence I can offer to suggest are things like benchmarking and overall heat output. For example, in Windows under full Prime95 load at 4.1GHz the CPU settles at around 85C, or basically just barely below what would be a critically high temperature. It IS below it though, so I'm fine with that. In Linux, under full Prime95 load the temperature doesn't break 65C. Similarly, in BSD, when compiling something huge like KDE4 with 12 threads, the temp is around 70C. In Linux it wont break 55C. Clearly there is a difference. This isn't just a matter of false reporting.

If necessary I could provide some proof of this, and possibly also some kind of benchmarks, it would just require me rebooting another 8 times to get it, which is annoying. Based on the the (technically anecdotal) evidence above I am quite convinced that the overclock is not being applied in Linux, and is in the other systems. Recall that I did have to explicitly tell FreeBSD's power managment daemon (powerd) to leave the settings at max at all times (ie powerd_flags='-n max -b max -a max'), and only then did I see the frequencies and temperatures go up. I doubt I've provided info that would be all that helpful though, so if need be I can be more thorough here.

Last edited by RoflCopter4 (2017-10-20 00:59:51)

seth · 2017-10-20 07:19:35

sudo dmidecode | grep -i speed

Have a look at https://aur.archlinux.org/packages/msr-tools/ - be careful when writing those registers.
Since the pstates do not align to frequencies, I'd assume that 100% gets you the full (overclocked) performance and the frequencies are just read from the CPU.

I'd suggest to benchmark the cpu (a single core!) on overclocked and (under)clocked BIOS settings and check whether you can spot a difference.
"Overclocking" is pretty much a dead concept from single-core times. Modern CPUs have a thermal budget to distribute among the cores - and easily exceed the announced frequency on a single core on demand.
You can probably drive them faster but I'm unsure whether you can exceed the thermal budget.

RoflCopter4 · 2017-10-24 02:09:42

seth wrote:

sudo dmidecode | grep -i speed
Have a look at https://aur.archlinux.org/packages/msr-tools/ - be careful when writing those registers.
Since the pstates do not align to frequencies, I'd assume that 100% gets you the full (overclocked) performance and the frequencies are just read from the CPU.
I'd suggest to benchmark the cpu (a single core!) on overclocked and (under)clocked BIOS settings and check whether you can spot a difference.
"Overclocking" is pretty much a dead concept from single-core times. Modern CPUs have a thermal budget to distribute among the cores - and easily exceed the announced frequency on a single core on demand.
You can probably drive them faster but I'm unsure whether you can exceed the thermal budget.

I have to say that I tried to mess around with what you linked here and got absolutely nowhere. It quickly became apparent that I can't tell a CPU register from a cash register and would just wreck things, that is if I figured out how to do anything in the first place.

Regardless, I believe I have found a solution, although it's not the nicest one. After a lot more sleuthing online I found one cryptic reference in a forum to someone else who has had this problem. It was remarkably difficult to find anyone else reporting this, and I believe I now know why. The solution is to disable Intel's microcode. This seemed ludicrous at first, and I ignored it and installed Slackware to see whether systemd was somehow at fault here. In Slackware setting the governor to performance had exactly the same effect as in FreeBSD; it worked perfectly. Despite this, it made no sense for the problem to by systemd, it has nothing to do with this. I then realized that the only thing in common between my installation of Slackware and FreeBSD, and in contrast to Arch Linux, is the fact that I have Grub set to load Intel's microcode in the latter and couldn't be bothered to do it for either of the former operating systems. I removed the line from grub.cfg and lo and behold everything works perfectly.

My potentially crackpot explanation for this is the simple fact that probably 95% of the people crazy enough to drop $600 on a CPU over the past year or so have opted to buy the nearly objectively superior AMD Ryzen chips rather than an i7 6800 series chip as I foolishly did. Of those people, the percentage using linux at all is not going to be very large, and of that small portion of what is already a small group of people, the ones who will both explicitly load Intel's microcode and then proceed to check their CPU clock speed is smaller still. This leaves very, very few people to actually report any bugs. Actually, other than myself and that one forum post, I couldn't find any others. It is very possible that this is nothing more than a bug in the microcode. Removing it made it go away. Adding it again made it come back. Not using the microcode is probably not a good idea generally, but given that it breaks cpufreq, I will not be using it.

Or maybe I'm crazy.

Anyway, thanks to everyone for the effort. At the end of the day, this doesn't seem to have been an Arch Linux specific problem at all, so I've mostly wasted your time. Maybe I should complain to Intel, but I doubt they'd listen.

Last edited by RoflCopter4 (2017-10-24 02:10:25)

Arch Linux

#1 2017-10-19 16:09:59

Unable to override cpufreq/intel pstate horrific throttling of CPU.

#2 2017-10-19 17:13:46

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

#3 2017-10-19 17:16:20

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

#4 2017-10-19 18:23:32

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

#5 2017-10-19 18:34:34

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

#6 2017-10-19 18:35:23

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

#7 2017-10-19 21:07:28

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

#8 2017-10-19 21:35:46

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

#9 2017-10-19 22:15:13

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

#10 2017-10-19 22:31:56

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

#11 2017-10-19 22:39:30

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

#12 2017-10-20 00:14:32

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

#13 2017-10-20 00:38:21

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

#14 2017-10-20 00:58:49

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

#15 2017-10-20 07:19:35

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

#16 2017-10-24 02:09:42

Re: Unable to override cpufreq/intel pstate horrific throttling of CPU.

Board footer