# [solved] Throttled CPU after Kernel upgrade 5.4 -> 5.10

## bheinze

Hello everyone,

some time ago I upgraded the kernel gentoo-sources from 5.4.97 to 5.10.27. Afterwards I noticed that the CPU doesn't get so hot anymore while compiling ebuilds. Coincidently the ebuilds now take approximately 2.5 times longer than with the old kernel. So it seems like the CPU gets somehow throttled.

What I tried so far:

Update kernel config with make olddefconfig (first I used make oldconfig)

compare the output of lscpu

compare the output of dmidecode

compare the output of /proc/cpuinfo

The only difference I found is that with kernel 5.4 I have Virtualization VT-x active. However I'm not using it actively, and I didn't knowingly disable it for kernel 5.10.

I'm running a Thinkpad T430 with an Intel i5-3320M cpu. Has anyone a pointer where to look for the cause of the slow system?

Thanks for your help!Last edited by bheinze on Thu May 20, 2021 5:00 pm; edited 1 time in total

----------

## Ralphred

Check your 

```
/sys/devices/system/cpu/cpufreq/policy*/scaling_governor
```

I had some oddity with that post 5.4...

----------

## Goverp

AFAIR sometime in the recent past few kernels, the governors defaults started changing between ondemand and schedutil and possibly even powersave.  Check your config for _CONFIG_CPU_FREQ entries in case you're not getting what you expect.

----------

## Ralphred

 *Goverp wrote:*   

> check _CONFIG_CPU_FREQ entries in case you're not getting what you expect.

 

I did that when it started to use schedutil, I still had ondemand as the default set in the kernel, and it completely ignored it.

I does't bother me that much as I have wrapper scripts for games that switch it between "whatever" and "performance", but I can imagine it being an issue on a laptop.

----------

## bheinze

Thanks all, the governor was a good starting point, however in fact the intel_pstate-driver is to blame:

With kernel 5.4.97:

```
~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver 

intel_pstate

~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

powersave
```

With kernel 5.10.27:

```
~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver 

intel_cpufreq

~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 

powersave
```

While I initially (as well) blamed a modified powersave governor, however as I now learned: intel_pstate brings its own governor.

 *Quote:*   

>  For this reason, CPUFreq allows scaling drivers to bypass the governor layer and implement their own performance scaling algorithms. That is done by the intel_pstate scaling driver.
> 
> https://www.kernel.org/doc/html/latest/admin-guide/pm/cpufreq.html

 

 *Quote:*   

> intel_pstate can operate in two different modes, active or passive. In the active mode, it uses its own internal performance scaling governor algorithm or allows the hardware to do performance scaling by itself, while in the passive mode it responds to requests made by a generic CPUFreq governor implementing a certain performance scaling algorithm.
> 
> https://www.kernel.org/doc/html/latest/admin-guide/pm/intel_pstate.html

 

Starting with kernel 5.7 the intel_pstate driver no longer works with my old cpu, hence the change to cpufreq, which indeed falls back to powersave.

 *Quote:*   

> intel_cpufreq
> 
> Starting with kernel 5.7, the intel_pstate scaling driver selects “passive mode” aka intel_cpufreq for CPUs that do not support hardware-managed P-states (HWP), i.e. Intel Core i 5th gen. or older.
> 
> https://linrunner.de/tlp/settings/processor.html

 

So now I'm trying my luck using schedutil governor.  :Smile: 

Thanks for your advice!

----------

## dmpogo

I always considered intel_pstate to be superior governor (when it uses its one).  It is interesting that newer kernels have intel-pstate that dropped support for old CPU's that where previously supported. If so, for me it would be an argument to stick to older kernel.

----------

## ilightwas

 *bheinze wrote:*   

> Thanks all, the governor was a good starting point, however in fact the intel_pstate-driver is to blame:
> 
> Starting with kernel 5.7, the intel_pstate scaling driver selects “passive mode” aka intel_cpufreq for CPUs that do not support hardware-managed P-states (HWP), i.e. Intel Core i 5th gen. or older.
> 
> https://linrunner.de/tlp/settings/processor.html
> ...

 

 *dmpogo wrote:*   

> I always considered intel_pstate to be superior governor (when it uses its one).  It is interesting that newer kernels have intel-pstate that dropped support for old CPU's that where previously supported. If so, for me it would be an argument to stick to older kernel.

 

I had the same issue as you, with a 4th gen i7 4790k. I did a kernel upgrade from the same version 5.4.97 to 5.10.27, using olddefconfig and changing nothing from my previous config.

By default the system was sluggish as hell because of the frequency being locked at the lowest, using the intel_cpufreq and the powersave governor

Looking more into it I found out that you can still use the intel_pstate. All you have to do is pass intel_pstate=active as a kernel arg.

Still changing nothing in my config I got the previous behavior and the system is perfect.

For more details

----------

## Jaglover

 *Quote:*   

> using olddefconfig and changing nothing from my previous config

 

Something may have changed, make target you used is "do whatever you want to my kernel and don't tell me", I would never do this to my kernel.

I wonder if P-States driver is present and ACPI is not, do you still need intel_pstate=active? I guess not.

----------

## eccerr0r

I'd call this a bug, even if it still functions correctly...

Then again nobody calls computer slowdowns by software changes as bugs, they call it... "new features"

(Suspecting I'll run into this issue on my machine, sigh.  At least it won't overheat in the current heat wave.)

----------

## figueroa

This calls for a do-over. Do you still have your kernel 5.4.97 configuration. Upgrade to current stable 5.4 (now 109) using make oldconfig. Then, be happy, or try to upgrade again to 5.10, but using make oldconfig. (Me, I'm using 5.4 for next 3-4 years.)

----------

## eccerr0r

Incidentally it looks like I upgraded my i5-3317U to 5.10.27 a few weeks ago, and apparently I had the config file set in a way such that transferring the 5.4.97 config seemed to not make that much of a difference in speed by default.  Perhaps I had more than the absolute minimum selected.  Normally I make menuconfig and do a quick check of the options when I upgrade, so it might be a different situation here...

----------

## figueroa

 *eccerr0r wrote:*   

> ...  I had the config file set in a way such that transferring the 5.4.97 config seemed to not make that much of a difference in speed by default. ...

 

That's kind of cryptic. When you do such an upgrade do you run make oldconfig on it before menuconfig? I kind of rely on oldconfig to help me catch changes. For a while I used make olddefconfig blindly following the kernel upgrade wiki, but realized that was not helping me learn anything.

Sometime in the last year, kernel updates switched me to P-States CPU frequency management without much explanation, which was very confusing for a while, but I've been happy with the results on my i7-2600. I've been on Gentoo Sources 5.4.109 since April 2, trying to follow amd64 stable closely.

----------

## eccerr0r

I'm not exactly sure what I had in my .config, but every time a kernel comes out, I copy the .config to the new kernel and run menuconfig from scratch, I never run oldconfig.  Menuconfig tends to also correct changes but you're right, it usually does not tell me what are no longer available (sometimes when I exit it gives a few warnings).  However I do scan over all the options to see if there are any that are blatantly incorrect, like making sure the network drivers are still there, etc.

I have not gone through the update on my big iron machine (the i7) yet, it's been having overheating problems.  The i5 has been as well, but it seems to always boot properly - just throttles and sometimes gets real slow and later pops back to normal.  Not so with my i7...it doesn't even seem to want to automatically throttle when it's at the 90°C mark, just overheats and beeps...

Gone are the days of the core2 machines behavior...always staying at the same speed.  Then again turboboost does sound like the right solution if you're only running one thread.  Alas when running Gentoo and running make -j ... turbo boost is not going to help that.  When the weather is cooler the i7 isn't too much slower when running all cores versus one core (3.9GHz vs 3.5GHz), but the i5 it's a dog when it can't turboboost (2.6GHz vs 1.7GHz).

Despite that, oddly enough, the (newer) i5 with 2C4T and turboboost issues, it still gives my Core2 Quads (4C4T 2.6GHz 100%) a run for their money building rust...

----------

## figueroa

Sounds like time to reseat the i5 & i7 CPUs and give the heatsink a good blow. Nothing quite like hauling the whole box outside and putting the shop-vac on blow.

----------

## eccerr0r

Nah, it's just hot out (or in) now.  When ambient is 27°C there's just that much less thermal margin.

What's weird is that core2 quads don't seem to get as hot as the i5/i7 do, which is somewhat baffling to me.  Maybe the sensors are misreporting CPU temperatures but they stay just a few degrees above ambient, maybe only 2°C or so when idling, unlike the i5/i7 which usually stay 8-10°C when idling.  I think all are using their stock CPU HS/F's.

Granted the i5 is a laptop.

----------

## ilightwas

 *Jaglover wrote:*   

>  *Quote:*   using olddefconfig and changing nothing from my previous config 
> 
> Something may have changed, make target you used is "do whatever you want to my kernel and don't tell me", I would never do this to my kernel.
> 
> I wonder if P-States driver is present and ACPI is not, do you still need intel_pstate=active? I guess not.

 

I diffed the configs and only saw defaults for some different new stuff, my previously set configs remained the same. That's what I expected from reading what olddefconfig would do vs oldconfig. Maybe I am missing something here? In any case I will eventually take the time to study more about the settings, old and new that I don't get yet.

Setting the pstate to active is only for the new kernel, if you use the pstate powersave governor, which I do. Maybe it's a bug, if you read the reddit discussion, it's a weird interaction.

----------

## sl70

I had the same problem. I read this thread but didn't know how to add the intel_pstate kernel option, and couldn't tell from the other messages in the thread whether it was even a good thing to do. However, I found this thread that suggested changing one line in the .config file:

 *Quote:*   

> Try to set the cpufreq governor to schedutil (CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL to be default)

 

It worked great and was easy to do.

----------

