CPU Throttling not working as expected

Hardware
1

We have an IPFire Duo Box where I have enabled power throttling with cpufreq-set -c 0 -g powersave (also for the second core). EIST has been enabled in the BIOS. The graph looks like it is throttling, but there is so little deviation that I think this is not working correctly. At least on weekends, there should be a significant dent in the curves.

Clipboard-1
Clipboard-11233×381 55.9 KB

Here is cpufreq-info and /proc/cpuinfo (for one core):

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
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: 800 MHz - 1.40 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 800 MHz and 1.40 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 1.40 GHz.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 69
model name      : Intel(R) Celeron(R) 2957U @ 1.40GHz
stepping        : 1
microcode       : 0x26
cpu MHz         : 1396.723
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer xsave rdrand lahf_lm abm cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust erms invpcid xsaveopt dtherm arat pln pts md_clear flush_l1d
vmx flags       : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds mmio_unknown
bogomips        : 2793.59
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

Does the graph look suspicious or is it just behaviour to be expected?

2

I am not expert on any of this by a long chalk but looking up the Celeron 2957U processor it is a Haswell version which came after the Sandy Bridge processor code name.

Since Sandy Bridge Intel chips are using the built in intel_pstate module.

intel_pstate This driver implements a scaling driver with an internal governor for Intel Core (Sandy Bridge and newer) processors.

From my understanding that means that it no longer uses the old kernel driver but one that is built in to the cpu and uses different algorithms for the governor setting application.

So maybe cpufreq is using its algorithm to decide the freq to set but the cpu chip is ignoring it and doing its own thing.

I found the following statement in an Arch Linux wiki page on cpu frequency scaling.

The intel_pstate CPU power scaling driver is used automatically for modern Intel CPUs instead of the other drivers below. This driver takes priority over other drivers and is built-in as opposed to being a module. This driver is currently automatically used for Sandy Bridge and newer CPUs. The intel_pstate may ignore the BIOS P-State settings. intel_pstate may run in “passive mode” via the intel_cpufreq driver for older CPUs. If you encounter a problem while using this driver, add intel_pstate=disable to your kernel line in order to revert to using the acpi_cpufreq driver.

Maybe you could try the suggestion to disable the intel_pstate in the kernel line. Whether it helps or not depends on if the intel_pstate is doing a good job or not. Maybe it can save power without having a huge impact on the frequency.

I just found the following note in the same Arch Linux wiki page:-

the internal powersave governor for Intel CPUs using the intel_pstate driver is equivalent to schedutil).

Governor ----- Description
performance ----- Run the CPU at the maximum frequency, obtained from /sys/devices/system/cpu/cpuX/cpufreq/scaling_max_freq.
powersave ----- Run the CPU at the minimum frequency, obtained from /sys/devices/system/cpu/cpuX/cpufreq/scaling_min_freq.
userspace ----- Run the CPU at user specified frequencies, configurable via /sys/devices/system/cpu/cpuX/cpufreq/scaling_setspeed.
ondemand ----- Scales the frequency dynamically according to current load. Jumps to the highest frequency and then possibly back off as the idle time increases.
conservative ----- Scales the frequency dynamically according to current load. Scales the frequency more gradually than ondemand.
schedutil ----- Scheduler-driven CPU frequency selection [4], [5].

2 Likes
3

Thanks for the detailled information. As this is a production firewall, I’d rather not change the kernel line even if this might be safe for the moment. Frequency is not that important.

1 Like
4

It might also be that the intel_pstate driver with the schedutil governor is able to achieve the best power saving by a combination of freq and voltage and hence not reduce the frequency as much as the acpi_cpufreq driver with the powersave governor that deals with frequency alone.