OM Lx 3 running a little hot lately? (CPU temp)

Support
21

It is related to the graphic card not to CPU, isn’t it?

Not all governors are available for all CPU, especially for Intel ones. You may check which governor you can use with he following command:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_governors
22

That would be yes.

I already know that one, there are 2, performance and powersave. The issue seems to be that tuned.service doesn’t use either one and the default set-up in OM Lx 3 has cpupower disabled. Which is why the work around described here is designed to allow cpupower to govern the CPU and tuned to govern everything else that it normally governs. Post edit: If there is a way to do this with tuned I haven’t found it and no one is telling me.

Again with the default set-up in OM Lx 3 this computer and a notebook (with older Intel CPU) the CPU frequency is at or very near maximum all the time. That does not seem like a good thing to me. Would think other users with Intel CPU’s would want to check this and if they find the same results I do maybe give some thought/research to whether this is OK with them.

23

Here is from an (old) Intel processor I use with omdv:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance schedutil

and I am using conservative governator with tuned service on and cpupower service off, but I don’t remember if I set this by hand or not.

Maybe this can help you.

24

With cpupower.service enabled the powersave governor works just fine. The issue is that it does not work at all with default OM Lx 3 settings. That is because with default OM Lx 3 settings cpupower.service does not and can not work.

OK right now I’m in a freshly installed default install of Lx 3.03 fully updated no testing repos.

$ systemctl status cpupower.service
● cpupower.service - Configure CPU power related settings
   Loaded: loaded (/lib/systemd/system/cpupower.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

Notice that cpupower.service is enabled but inactive (dead). Why? Because there is set a Conflicts in tuned.service. This is from my OM Lx 3 default ‘/lib/systemd/system/tuned.service’:

[Unit]
Description=Dynamic System Tuning Daemon
After=systemd-sysctl.service network.target dbus.service
Requires=dbus.service polkit.service
Conflicts=cpupower.service
Documentation=man:tuned(8) man:tuned.conf(5) man:tuned-adm(8)
ConditionVirtualization=no

[Service]
Type=dbus
PIDFile=/run/tuned/tuned.pid
BusName=com.redhat.tuned
ExecStart=/usr/sbin/tuned -l -P

[Install]
WantedBy=multi-user.target

so cpupower can’t work. No cpupower=no governor, at least on my hardware.

Manually enable cpupower.service, which is not that hard but is a bit of a process, and powersave governor works just fine.

25

Thanks @mandian. FWIW: This is a quote form the link @mandian provided:

“The intel_pstate driver knows the details of the how the CPU works and it does a better job than the generic ACPI solution”

"intel_pstate offers only two governors, powersave and performance. Intel claims that the intel_pstate “powersave” is faster than the generic acpi governor with “performance”

otherwise I can do anything and everything in that article and it won’t matter unless I manually intervene and enable cpupower.service.

Post edit: And both computers I’m talking about use intel_pstate for CPU driver. I discovered that long ago.

1 Like
26

Here is where i learned about modern Intel CPU governor. The latest link in that page is interesting too.

27

Thanks @mandian. Here is what that wiki page says about cpupower (italics added by me):

"cpupower

cpupower is a set of userspace utilities designed to assist with CPU frequency scaling. The package is not required to use scaling, but is highly recommended because it provides useful command-line utilities and a systemd service to change the governor at boot.

The configuration file for cpupower is located in /etc/default/cpupower. This configuration file is read by a bash script in /usr/lib/systemd/scripts/cpupower which is activated by systemd with cpupower.service. You may want to enable cpupower.service to start at boot."

Which is what the workaround I got from Gabriel Craciunescu does. It enables cpupower.service to work from boot in OM Lx 3.03.

Post edit: I’ve done a lot of reading on this issue. It is my understanding currently that The intel-pstate powersave mode should be the equivalent of the acpi-cpufreq ondemand mode. Also the acpi-cpufreq is a driver for older hardware as in the ondemand governor. The workaround I am using has the advantage that it is based on the CPU manufacturers design and specifications.

1 Like