Can't get the scaling right for this CPU

General system Kernel, boot, graphics & hardware
1

I have tried to get the CPU scaling right for this Intel-based system but It seems I am not succeeding.

Linux arch-gnome 5.18.10-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Thu, 07 Jul 2022 17:18:11 +0000 x86_64 GNU/Linux

CPU:
  Info: model: Intel Core i7-8565U bits: 64 type: MT MCP arch: Whiskey Lake
    gen: core 8 built: 2018 process: Intel 14nm family: 6 model-id: 0x8E (142)
    stepping: 0xB (11) microcode: 0xF0
  Topology: cpus: 1x cores: 4 tpc: 2 threads: 8 smt: enabled cache:
    L1: 256 KiB desc: d-4x32 KiB; i-4x32 KiB L2: 1024 KiB desc: 4x256 KiB
    L3: 8 MiB desc: 1x8 MiB
  Speed (MHz): avg: 1167 high: 3039 min/max: 400/4600 scaling:
    driver: intel_pstate governor: powersave cores: 1: 900 2: 900 3: 900 4: 900
    5: 900 6: 901 7: 900 8: 3039 bogomips: 31999

I am using cpupower to set the governor to powersave via cpupower.service at boot using the config at /etc/default/cpupower:

# Define CPUs governor
# valid governors: ondemand, performance, powersave, conservative, userspace.
governor='powersave'

# Limit frequency range
# Valid suffixes: Hz, kHz (default), MHz, GHz, THz
# min_freq="400MHz"
# max_freq="4600MHz"

# Specific frequency to be set.
# Requires userspace governor to be available.
# Do not set governor field if you use this one.
#freq=

# Utilizes cores in one processor package/socket first before processes are 
# scheduled to other processor packages/sockets.
# See man (1) CPUPOWER-SET for additional details.
#mc_scheduler=

# Utilizes thread siblings of one processor core first before processes are
# scheduled to other cores. See man (1) CPUPOWER-SET for additional details.
#smp_scheduler=

#  Sets a register on supported Intel processore which allows software to convey
# its policy for the relative importance of performance versus energy savings to
# the  processor. See man (1) CPUPOWER-SET for additional details.
#perf_bias=
# vim:set ts=2 sw=2 ft=sh et:

cpupower frequency-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: 400 MHz - 4.60 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.60 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 2.48 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

I have been keeping an eye on the CPU frequency with htop and it seems that it idles at 2000MHz almost all the time on all the cores and just very rarely goes down to 800-900 MHz on one or another core but never below.

I would expect lower CPU frequencies when the governor is set to powersave since the CPU has the lowest hardware limit of 400 MHz.

I am not sure if I have missed some steps or misunderstood something with regard to CPU scaling as described in the ArchWiki.

Any help/suggestions/pointers/comments are highly appreciated.

2

Here is a screenshot of s-tui for visual info:

Screenshot from 2022-07-08 12-28-19

3

Try playing with this: https://wiki.archlinux.org/title/CPU_frequency_scaling#Intel_performance_and_energy_bias_hint

It should influences how aggressively it scales up the frequency.

1 Like
4

Great!

Thanks for the pointer! I somehow always scrolled past the section it seems, my bad :person_facepalming:t5:

Will the following set the value for “epb” on-the-fly?

# echo *epb* > /sys/devices/system/cpu/cpu*/power/energy_perf_bias

And then I could make it permanent by setting:

#  Sets a register on supported Intel processore which allows software to convey
# its policy for the relative importance of performance versus energy savings to
# the  processor. See man (1) CPUPOWER-SET for additional details.
#perf_bias=

in the /etc/default/cpupower ?

Edit: The default epb is set to 6

cat  /sys/devices/system/cpu/cpu*/power/energy_perf_bias
6
6
6
6
6
6
6
6

Edit:
I set the epb value for all the cores to 15 but it doesn’t seem to make any difference.
I am going to set it in /etc/default/cpupower and test.

# cat  /sys/devices/system/cpu/cpu*/power/energy_perf_bias
15
15
15
15
15
15
15
15
5

also make sure that power-profiles-daemon or others do not interfere… (TLP e.t.c. )

1 Like
6

I don’t have TLP installed.
Also, I have disabled power-profiles-daemon as well before starting to use cpupower.

I did now:

# cpupower set -b 15

but the situation remains the same as described in the op. I am stumped :confused:

The only method remaining is:

# x86_energy_perf_policy *epb*

I am going to try it and report back.

Edit:

Tried: x86_energy_perf_policy 15 as well. Still the same.

Also, in /etc/default/cpupower, set perf_bias= to 15 (and also “15”, unsure of the syntax), restarting the cpupower.service and/or rebooting seems not to have any effects.

:frowning_face:

7

What if you use the ondemand or schedutil governor?

8

It seems the only supported governors are powersave and performance according to
cpupower frequency-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: 400 MHz - 4.60 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.60 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.32 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes


$ sudo cpupower frequency-set -g ondemand 
Setting cpu: 0
Error setting new values. Common errors:
- Do you have proper administration rights? (super-user?)
- Is the governor you requested available and modprobed?
- Trying to set an invalid policy?
- Trying to set a specific frequency, but userspace governor is not available,
   for example because of hardware which cannot be set to a specific frequency
   or because the userspace governor isn't loaded?
9

In the output from inxi -aC, it says:

driver: intel_pstate governor: powersave cores: 1: 900 2: 900 3: 900 4: 900
    5: 900 6: 901 7: 900 8: 3039 bogomips: 31999

but I seem not to be able to get it down to even 900MHz at idle (let alone 400MHz supported by the hardware).

I would think the difference between 900MHz and 2000MHz would make a significant difference in power saving :thinking:

10

sudo cpupower frequency-set -u 900

does not work?

11

:wink:

1 Like
12

Yeah, I know!

It was for demonstration! :sweat_smile:

13

This seems to have produced a rather interesting and somewhat unexpected effect.

Even thought that the CPU freq at idle is still 2000MHz for the most part, some of the cores falls occasionally down to 400MHz.

Color me confused!
(well, more than usual :wink:)

14

… it should set all cores to the same frequency.

but if you have some implementation running that does set frequencies it will get overwritten.
or … there is some missing setup needed for the CPU… like mine here:

1 Like
15

That is what I expected it do as well.

I can’t think of anything else that could set frequencies apart from cpupower.
Can you think of anything I should be looking at?

Edit:

Ah, just saw your link. I’ll have a look.

16

You use gnome it seems?
I’m not a gnome user, but doesn’t it also have some power related options in the settings there?

2 Likes
17

Yes, it uses power-profiles-daemon by default and you get the power options in the settings.
However, It was still the same using it so that’s why I disabled it in favor of cpupower.

18

have you try

sudo turbostat
1 Like
19

If I remember correctly disabling power profiles daemon does not produce the intended results, it needs to be masked.

1 Like
20

Right. I should have been more clear. I did disable and masked it since it got started at boot as a “dependency” of the control-center, I believe. Thanks for pointing it out though!