dietpi-config only has CPU Governor "performance" and "powersave"

Hello there!

I installed dietpi no a x86_64 Machine and wanted to change CPU Governor to conservative or ondemand to lower the power consumption and heat dissipation.

In dietpi-config there are only “performance” and “powersave” as options to choose from.

Before I go and change some textfiles to change the CPU Governor I just wanted to ask if there is any reason why there are no options like “ondemand” and “conservative” in the dietpi-config tool.

And what would be the best way to set up a CPU Governor “conservative” in dietpi?!

Thank you very much for your help and suggestions.
Greetings! :slight_smile:

DietPi-Config shows you all governors which are available on your system. Please verify via:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

Or do you have multiple CPU types with different available governors?

cat /sys/devices/system/cpu/cpufreq/policy1/scaling_available_governors

I also counter check my intel nuc & only “PERFORMANCE” AND “POWERSAVE” available in dietpi-config. provided commands also shown only these two options available.

root@DietPi:~# cat /sys/devices/system/cpu/cpufreq/policy1/scaling_available_governors
performance powersave
root@DietPi:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
performance powersave

looks like your CPU doesn’t support other mods

this time my system works on “performance mode”. Do you recommend to change it to “powersave mode” . as in one forum it is written intel powersave mode similar to on demand. please give your expert suggestion. my nuc only running adguard, unbound, plex & wireguard via docker compose. & 99% of daytime cpu load less then 1%. CPU command shows this thing

root@DietPi:/mnt/dietpi_userdata# cpu

 DietPi CPU Info
 Use dietpi-config to change CPU / performance options
 Architecture |     x86_64
 Temperature  |     39'C : 102'F (Cool runnings)
 Governor     |     performance

                 Current Freq    Min Freq   Max Freq
 CPU0         |      1344 MHz      1332 MHz    2415 MHz
 CPU1         |      1414 MHz      1332 MHz    2415 MHz
 CPU2         |      1599 MHz      1332 MHz    2415 MHz
 CPU3         |      1333 MHz      1332 MHz    2415 MHz

[ INFO ] DietPi-CPU_info | CPU current frequency, may be affected by this script, due to the processing required to run it.

Thank you for your help and answers/questions.

The x86_64 Box in question is a Dell Wyse 5070 with a Intel Celeron™ J4105 Processor.

All C-States are also enabled in BIOS.

Following some outputs:

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
performance powersave

# cat /sys/devices/system/cpu/cpufreq/policy1/scaling_available_governors
performance powersave

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

# cpu

 DietPi CPU Info
 Use dietpi-config to change CPU / performance options
 Architecture |     x86_64
 Temperature  |     35'C : 95'F (Cool runnings)
 Governor     |     performance

                 Current Freq    Min Freq   Max Freq
 CPU0         |      1773 MHz      800 MHz    2500 MHz
 CPU1         |      1758 MHz      800 MHz    2500 MHz
 CPU2         |      819 MHz      800 MHz    2500 MHz
 CPU3         |      683 MHz      800 MHz    2500 MHz

So, the last days I didn’t have much time to get deeper into resolving this issue but it seems that Intel is using a different/new Power Scaling Driver (intel_pstate) as of Codename Sandy Bridge and newer CPUs.
The old acpi_cpufreq CPU Scaling Driver was used up to Codename Nehalem/Westmere CPUs.

With the newer scaling driver performance and powersave are the only CPU Scaling Governors available. So the governors ondemand and conservative (which I was used to) are not available anymore with these new drivers.

So I monitored the CPU frequency (with “watch cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq”) over some time and saw that the cores are scaling between 700MHz and 2500Mhz. The CPU Governor of this Dell ThinClient was set to performance so I thought that the CPU would clock to max_cpufreq 2500MHz constantly. Then I read (Here in the ArchWiki) that the behavior of performance of the old acpi_cpufreq compared to the identically named governor of the new intel_pstate Power Scaling Drivers is different.

Here a small excerpt of the ArchWiki:

Note: The intel_pstate driver supports only two governors: powersave and performance. Although they share the name with the generic governors, they do not work in the same way as the generic governors. Both intel_pstate governors provide dynamic scaling similar to the schedutil or ondemand generic governors. > The performance governor provided by intel_pstate should give better power saving functionality than the old ondemand governor.

Sorry for the unnecessary long post. So following the TLDR:

So in conclusion

  • The newer intel_pstate Power Scaling driver which is used by default on CPUs starting from Intel Sandy Bridge only provides CPU Scaling Governors powersave and performance.

  • The CPU Governor named performance of the old acpi_cpufreq behaves differently compared to the identically named CPU Governor of the newer intel_pstate Power Scaling Driver.

  • The CPU Governor performance of the newer intel_pstate Driver behaves similar to the ondemand CPU Governor of the old acpi_cpufreq driver. It even should give better powersaving functionality compared to the old ondemand CPU Governor.

So leave it at performance or if you need to clock the Cores to the min frequency then use powersave.
If you want to cap the Frequency at a custom max clock then you can change the max Frequency of the performance governor with dietpi-config.

I didn’t read all the information I was browsing throgh in every detail and didn’t want to go into that rabbit hole.
I know myself: Once you “clock” you can’t stop. :wink: So YMMV.


The Intel pstates scaling driver is actually not better but worse than the Linux native CPUfreq (average power usage vs responsiveness), from all I read about it. But I guess it also depends on Linux version and Intel CPU/chip.

But it makes sense that we detect and correctly handle the Intel driver, hence do not show and try to apply CPUfreq governor settings in this case. Can you please page the output of:

for i in /sys/devices/system/cpu/intel_pstate/*; do echo "$i: $(<$i)"; done

I have an old Intel notebook here to compare with, and and Ivy Bridge as well, so we should be able to see the different shades.

Also nice would be the option to switch between Intel driver and CPUfreq. Can you show the loaded modules?



the output of given command is as

root@DietPi:~# for i in /sys/devices/system/cpu/intel_pstate/*; do echo "$i: $(<$i)"; done
/sys/devices/system/cpu/intel_pstate/max_perf_pct: 100
/sys/devices/system/cpu/intel_pstate/min_perf_pct: 55
/sys/devices/system/cpu/intel_pstate/no_turbo: 0
/sys/devices/system/cpu/intel_pstate/num_pstates: 14
/sys/devices/system/cpu/intel_pstate/status: active
/sys/devices/system/cpu/intel_pstate/turbo_pct: 36

Hey MichaIng. Yeah, having only two options for CPU Governor is lame. From what I have read in several Forums there are mixed experiences with the pstate Scaling driver.
An option to switch between Scaling Drivers would be awesome. :slight_smile:

Have a nice Weekend! :slight_smile:

Following the wanted output.

root@DietPi:~# for i in /sys/devices/system/cpu/intel_pstate/*; do echo “$i: $(<$i)”; done

/sys/devices/system/cpu/intel_pstate/max_perf_pct: 100
/sys/devices/system/cpu/intel_pstate/min_perf_pct: 32
/sys/devices/system/cpu/intel_pstate/no_turbo: 0
/sys/devices/system/cpu/intel_pstate/num_pstates: 18
/sys/devices/system/cpu/intel_pstate/status: active
/sys/devices/system/cpu/intel_pstate/turbo_pct: 56

root@DietPi:~# lsmod

Module                  Size  Used by
binfmt_misc            20480  1
tda18250               20480  1
mn88472                20480  1
xt_nat                 16384  15
xt_tcpudp              16384  29
veth                   20480  0
xt_conntrack           16384  4
ipt_MASQUERADE         16384  11
nf_conntrack_netlink    49152  0
xfrm_user              40960  1
xfrm_algo              16384  1 xfrm_user
nft_counter            16384  72
xt_addrtype            16384  2
nft_compat             20480  61
nft_chain_nat_ipv4     16384  12
nf_nat_ipv4            16384  2 ipt_MASQUERADE,nft_chain_nat_ipv4
nf_nat                 36864  2 nf_nat_ipv4,xt_nat
nf_conntrack          172032  6 xt_conntrack,nf_nat,ipt_MASQUERADE,nf_nat_ipv4,xt_nat,nf_conntrack_netlink
nf_defrag_ipv6         20480  1 nf_conntrack
nf_defrag_ipv4         16384  1 nf_conntrack
libcrc32c              16384  2 nf_conntrack,nf_nat
nf_tables             143360  351 nft_compat,nft_chain_nat_ipv4,nft_counter
nfnetlink              16384  4 nft_compat,nf_conntrack_netlink,nf_tables
br_netfilter           24576  0
bridge                188416  1 br_netfilter
stp                    16384  1 bridge
llc                    16384  2 bridge,stp
overlay               131072  3
tda18271               53248  2
drxk                   69632  2
nls_ascii              16384  1
nls_cp437              20480  1
vfat                   20480  1
fat                    86016  1 vfat
uas                    28672  2
usb_storage            73728  2 uas
em28xx_alsa            24576  0
intel_rapl             24576  0
snd_pcm               114688  1 em28xx_alsa
snd_timer              36864  1 snd_pcm
snd                    94208  3 em28xx_alsa,snd_timer,snd_pcm
soundcore              16384  1 snd
x86_pkg_temp_thermal    16384  0
intel_powerclamp       16384  0
coretemp               16384  0
i915                 1736704  0
kvm_intel             233472  0
dell_wmi               16384  0
kvm                   757760  1 kvm_intel
dell_smbios            28672  1 dell_wmi
wmi_bmof               16384  0
dell_wmi_descriptor    16384  2 dell_wmi,dell_smbios
drm_kms_helper        208896  1 i915
sparse_keymap          16384  1 dell_wmi
irqbypass              16384  1 kvm
crct10dif_pclmul       16384  0
crc32_pclmul           16384  0
dcdbas                 16384  1 dell_smbios
ucsi_acpi              16384  0
efi_pstore             16384  0
drm                   495616  3 drm_kms_helper,i915
ghash_clmulni_intel    16384  0
mei_me                 45056  0
intel_cstate           16384  0
tpm_crb                16384  0
evdev                  28672  0
intel_rapl_perf        16384  0
mei                   118784  1 mei_me
efivars                20480  1 efi_pstore
typec_ucsi             36864  1 ucsi_acpi
i2c_algo_bit           16384  1 i915
sg                     36864  0
idma64                 20480  0
wmi                    28672  4 dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
typec                  45056  1 typec_ucsi
pcc_cpufreq            16384  0
em28xx                 94208  3 em28xx_rc,em28xx_alsa,em28xx_dvb
tpm_tis                16384  0
tpm_tis_core           20480  1 tpm_tis
tpm                    65536  3 tpm_tis,tpm_crb,tpm_tis_core
tveeprom               24576  1 em28xx
video                  49152  2 dell_wmi,i915
rng_core               16384  1 tpm
v4l2_common            16384  1 em28xx
button                 20480  0
videodev              212992  1 v4l2_common
media                  45056  2 videodev,em28xx
efivarfs               16384  1
ip_tables              28672  0
x_tables               45056  7 xt_conntrack,nft_compat,xt_tcpudp,ipt_MASQUERADE,xt_addrtype,xt_nat,ip_tables
autofs4                49152  3
ext4                  745472  4
crc16                  16384  1 ext4
mbcache                16384  1 ext4
jbd2                  122880  1 ext4
crc32c_generic         16384  0
fscrypto               32768  1 ext4
ecb                    16384  0
sd_mod                 61440  10
mmc_block              45056  0
crc32c_intel           24576  9
ahci                   40960  3
libahci                40960  1 ahci
xhci_pci               16384  0
xhci_hcd              266240  1 xhci_pci
libata                270336  2 libahci,ahci
i2c_designware_platform    16384  0
i2c_designware_core    20480  1 i2c_designware_platform
scsi_mod              249856  5 sd_mod,usb_storage,uas,libata,sg
aesni_intel           200704  1
r8169                  90112  0
sdhci_pci              45056  0
cqhci                  28672  1 sdhci_pci
aes_x86_64             20480  1 aesni_intel
sdhci                  61440  1 sdhci_pci
crypto_simd            16384  1 aesni_intel
cryptd                 28672  3 crypto_simd,ghash_clmulni_intel,aesni_intel
glue_helper            16384  1 aesni_intel
realtek                20480  0
libphy                 77824  3 r8169,realtek
mmc_core              176128  4 sdhci,cqhci,mmc_block,sdhci_pci
fan                    16384  0
intel_lpss_pci         20480  0
i2c_i801               28672  0
intel_lpss             16384  1 intel_lpss_pci
mfd_core               16384  1 intel_lpss
usb_common             16384  2 em28xx_alsa,usbcore
thermal                20480  0

Found it:

You can verify whether your intel_pstate driver runs in active mode by checking if the following reports “intel_pstate”:

cat /sys/devices/system/cpu/cpufreq/policy0/scaling_driver

I see the pcc_cpufreq scaling driver module is loaded as well for some reason, should however not be in use. I found a patch which disabled all dynamic scaling governors for this driver when more than 4 CPUs are present:
If this was the case for someone, it could be tried to use the more generic acpi_cpufreq scaling driver instead, by blacklisting echo ‘blacklist pcc_cpufreq’ > /etc/modprobe.d/disable_pcc_cpufreq.conf. But if intel_pstate is used (verified above), it’s doesn’t play a role. The module can still be blacklisted to reduce memory usage a little.

So what we need to change is adjusting the governor text in dietpi-config, when intel_pstate runs in active mode, to reflect that both do dynamic frequency scaling, just more aggressive or conservative, respectively.

Given command give following result
root@DietPi:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_driver


So then all is perfectly fine and as expected. To decide whether powersave or performance is better, the statistics may help, e.g. check how long (aggregated) the CPU resides in which state:
cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
and check long-term average CPU temperature and responsiveness of applications. If powersave serves sufficient responsiveness, then there is not reason to waste energy :wink:. Both do clock up to max frequencies, in case of high load, if I understood it correctly, it’s just the question how quickly (intermediate steps or directly) and which CPU load breakpoint(s) are used. The stats in /sys/devices/system/cpu/cpufreq/policy0/stats/ after 1-2 days should give a hint.

last command give this result

root@DietPi:~# cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
cat: /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state: No such file or directory

this folder contains only these files

root@DietPi:/sys/devices/system/cpu/cpufreq/policy0# dir
affected_cpus     cpuinfo_min_freq            related_cpus                 scaling_cur_freq  scaling_governor  scaling_min_freq
cpuinfo_max_freq  cpuinfo_transition_latency  scaling_available_governors  scaling_driver    scaling_max_freq  scaling_setspeed

Dammit, no stats provided by intel_pstate driver then :frowning:.