LinuxQuestions.org - [SOLVED] Kernel config CPU Frequency Scaling / module and Intel "Turbo boost" behaviour

- Linux - Kernel (https://www.linuxquestions.org/questions/linux-kernel-70/)

- - Kernel config CPU Frequency Scaling / module and Intel "Turbo boost" behaviour (https://www.linuxquestions.org/questions/linux-kernel-70/kernel-config-cpu-frequency-scaling-module-and-intel-turbo-boost-behaviour-4175477496/)

Kernel config CPU Frequency Scaling / module and Intel "Turbo boost" behaviour

My stock Kernel configuration works ok, but I wanted to tweak it for several reasons. The new kernel is perfect, except...

My CPU is dual core "Intel Core i5-3317u" (http://ark.intel.com/products/65707) with a clock speed of 2x1.7Ghz. The CPU has a "turbo boost" up to 2.6GHz. When booting from my Mageia stock Kernel 3.8.13 the policy of CPU Frequncy Scaling is set to 799MHz to 1.7GHz per core, which is what I want. There are various other quirks in this Kernel that makes me want to swap to a customer one, which I have built.

My custome Kernel is 3.10.10 and based upon the configuration of the stock Kernel with several modifications. All in all the new Kernel is better, but the new Kernel sets my CPU clock speed to maximum 2.6GHz. It sets my lower level to 1.4GHz and operates the governor between those frequencies. This behaviour is not something I want. I want the turbo boost to function, but I also want my normal CPU range to be 799MHz to 1.7GHz.
I know I can set the behaviours manually by using CPUfrequency tools, but I am wondering why my governor automatically set my CPU clock speeds policy from 1.4GHz to 2.6GHz.
Does anyone have insights into the CPU Frequency modules that they could share with me?

The main difference in the ACPI --> CPU Frequency settings I did was to add several of the Intel Modules into the Kernel. My default governor is still the same. I did also add virtualisation support, some additional functions under "processor types and features" and some other things (Intel related drivers) that might effect the situation.

What does this mean? Does it mean that the turbo boost was not active in my stock kernel? Or does it mean my CPU frequency modules are now behaving incorrectly?
I suspect that it might have something to do with the "Intel Enhanced Speedstep" module.
I am trying to run a cheap system and want the clock speed to always be at a minimum for the requirements.

Any insight into CPUfrequencyscaling and Intel Turboboost would be highly appreciated.

Hi

Sorry, I didn't fully understand the question.
In the end, if you do a "cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state" what is the thing that you don't want to have?

Thank you

Thanks Pearlseattle, you put me on the right track. I was getting too impatient and looking in the wrong places!

As you see, here is the (almost)desired behaviour from my stock Kernel 3.8.13.4_mageia x86_64 GNU/Linux:

Code:

analyzing CPU 0:

  driver: acpi-cpufreq  <-- I "overlooked"(didn't think about at first) that  

  CPUs which run at the same hardware frequency: 0 1 2 3

  CPUs which need to have their frequency coordinated by software: 0

  maximum transition latency: 10.0 us.

  hardware limits: 799 MHz - 1.70 GHz

  available frequency steps: 1.70 GHz, 1.70 GHz, 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 900 MHz, 800 MHz, 799 MHz

  available cpufreq governors: ondemand, conservative, powersave, userspace, performance

  current policy: frequency should be within 1.70 GHz and 1.70 GHz.  <-- with AC, scales well without.

                  The governor "powersave" may decide which speed to use

                  within this range.

  current CPU frequency is 1.70 GHz. <-- needs tweaking, but no biggie

  boost state support:

    Supported: yes

    Active: yes

    25500 MHz max turbo 4 active cores

    25500 MHz max turbo 3 active cores

    25500 MHz max turbo 2 active cores

    25500 MHz max turbo 1 active cores

Below is the undesired effect I had after compiling and running my custom Kernel 3.11.1try x86_64 GNU/Linux. I eventually found out thanks that the effect was caused by the wrong driver! DOH. But only after going into /sys/devices/system/cpu/cpuX/cpufreq/ and exploring what was going on there. There was no stats folder! Hmm. I then returned to looking at the bigger picture in my "cpupower frequency-info".

Code:

analyzing CPU 0:

  driver: intel_pstate   <-- THE SINNER!! 

  CPUs which run at the same hardware frequency: 0

  CPUs which need to have their frequency coordinated by software: 0

  maximum transition latency: 0.97 ms.

  hardware limits: 800 MHz - 2.60 GHz  <-- THE PROBLEM 

  available cpufreq governors: performance, powersave

  current policy: frequency should be within 2.60 GHz and 2.60 GHz.  <-- ouch, but can be tweaked, but not the desired startpoint

                  The governor "powersave" may decide which speed to use

                  within this range.

  boost state support:

    Supported: yes

    Active: yes

    25500 MHz max turbo 4 active cores

    25500 MHz max turbo 3 active cores

    25500 MHz max turbo 2 active cores

    25500 MHz max turbo 1 active cores

The current status is much better. Custom Kernel 3.11.1try_again x86_64 GNU/Linux. Now I also have the stats finally:

Code:

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: 799 MHz - 1.70 GHz  <-- back to desired level, which was the main point

  available frequency steps: 1.70 GHz, 1.70 GHz, 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 900 MHz, 800 MHz, 799 MHz

  available cpufreq governors: ondemand, userspace, powersave, conservative, performance

  current policy: frequency should be within 799 MHz and 1.70 GHz.  <-- scaling well! no AC in this case

                  The governor "powersave" may decide which speed to use

                  within this range.

  current CPU frequency is 799 MHz.     <-- Perfect, but I need to tweak it as it always stay on max when using AC

  cpufreq stats: 1.70 GHz:2,49%, 1.70 GHz:0,00%, 1.60 GHz:0,02%, 1.50 GHz:0,00%, 1.40 GHz:0,03%, 1.30 GHz:0,01%, 1.20 GHz:0,03%, 1.10 GHz:0,02%, 1000 MHz:0,02%, 900 MHz:0,05%, 800 MHz:0,02%, 799 MHz:97,30%  (53)  <--- and now I also have the stats 

  boost state support:

    Supported: yes

    Active: yes

    25500 MHz max turbo 4 active cores

    25500 MHz max turbo 3 active cores

    25500 MHz max turbo 2 active cores

    25500 MHz max turbo 1 active cores

Lesson = don't use the wrong driver! (with all the Intel drivers in CPUfrequency in Kernel config it can get confusing).
Solution = disabled "intel p state" from Kernel
Note to self = "intel p state" overrides "acpi-cpufreq". "intel p state" does not work for my laptop.
other notes = "intel enhanced speedstep" and "intel pentium 4 clock modulation" still built in and do not interfere negatively
Whats next = idle state and thermal throttle :)

Any problems still? Yes... Kindof.. Not really, but could turn out to become one..

Code:

localhost ~]#cpufreqd-get

No cpufreqd socket found

hmm. I am wondering why that is. But I can use other tools to manage cpu frequency scaling..

hmm indeed.

I have compiled the Kernel a few more times now, optimising it. It works out great now. The sinner was definetely "Intel P state" module. A bit of patience and tuning made the situation great. It behaves just like I wanted.

Lesson learned. Choose the correct modules when using CPU Frequency Scaling! Or rather, don't add the wrong ones!