cpupower fails sometime to execute with this error : cpupower: error while loading shared libraries: libcpupower.so.0: cannot open shared object file: No such file or directory I've compiled and installed the last cpupower tool from sources on my workstation. The Makefile install command installs the libs in /usr/local/lib and my LD_LIBRARY_PATH is set accordingly : syl@WorkStation-T3500:~$ echo $LD_LIBRARY_PATH :/usr/local/lib/ lrwxrwxrwx 1 root root 20 juin 26 11:46 libcpupower.so -> libcpupower.so.0.0.1 lrwxrwxrwx 1 root root 20 juin 26 11:46 libcpupower.so.0 -> libcpupower.so.0.0.1 -rwxr-xr-x 1 root root 77048 juin 26 11:46 libcpupower.so.0.0.1 l A simple cpupower info query works nice : syl@WorkStation-T3500:~$ 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: 1.20 GHz - 3.20 GHz available cpufreq governors: performance powersave current policy: frequency should be within 1.20 GHz and 3.20 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency: Unable to call hardware current CPU frequency: 1.20 GHz (asserted by call to kernel) boost state support: Supported: yes Active: yes Nervetheless, here is what happens when I try to set some policy : syl@WorkStation-T3500:~$ sudo cpupower frequency-set --governor userspace cpupower: error while loading shared libraries: libcpupower.so.0: cannot open shared object file: No such file or directory May I ask you some hints about this strange issue ? All the best Sylvain

**Background Information:** I'm running Ubuntu 24.04.1 LTS (Noble Numbat, kernel 6.8.0-51-generic) on an AMD Ryzen 9 7950X3D, and I'm investigating some odd behavior where the CPU governor/driver will ***lower*** the CPU frequency when under full load. Using the performance governor and the amd-pstate driver, here's what I'm seeing: | Load | 15 min Load Avg | CPU Temp | CPU Frequency | | | ---- | :-------------- | -------- | ---------------: | -------- | | Idle | 1.12 | 40.8 C | 5,759,000,000 Hz | 5.76 GHz | | Full | 33.02 | 58.5 C | 4,827,047,000 Hz | 4.83 GHz | I'm fairly confident that 58.5C isn't hot enough to cause thermal throttling on the CPU, but I'd like to be sure so that I know how to direct my investigation: - If it's thermal throttling, I'll get a better cooling system. - If it's not thermal throttling, I'll keep looking into configuration options [This post](https://unix.stackexchange.com/questions/477088/cpu-thermal-throttle-counters?newreg=280449e8db7b4d9395891d3e0fe2fa4a) suggests that I should be able to see throttling information in /sys/devices/system/cpu/cpu*/thermal_throttle/, however the thermal_throttle directory is missing:

/sys/devices/system/cpu/cpu0 $ file *
acpi_cppc:        directory
cache:            directory
cpufreq:          symbolic link to ../cpufreq/policy0
cpuidle:          directory
crash_notes:      regular file, no read permission
crash_notes_size: regular file, no read permission
driver:           symbolic link to ../../../../bus/cpu/drivers/processor
firmware_node:    symbolic link to ../../../LNXSYSTM:00/LNXSYBUS:00/ACPI0010:00/ACPI0007:00
hotplug:          directory
microcode:        directory
node0:            symbolic link to ../../node/node0
power:            directory
subsystem:        symbolic link to ../../../../bus/cpu
topology:         directory
uevent:           ASCII text, with very long lines (1212)

**The Question:** Why is this missing from sysfs, and how can I get the CPU throttling information?

Intel Sandy-Bridge family i5 Core CPU, running Linux kernel 3.2 (Debian Squeeze/Wheezy), under heavy computation load, does not react to to cpufreq-set -g powersave (using acpi_cpufreq module). It is 99.9% time running in turbo mode, although it seems to be somehow throttled automatically, as can be seen in kernel messages (dmesg): ... [137547.968129] CPU2: Package temperature/speed normal [137547.968130] CPU0: Package temperature/speed normal [137548.124277] CPU2: Core temperature above threshold, cpu clock throttled (total events = 16455155) [137548.124280] CPU3: Core temperature above threshold, cpu clock throttled (total events = 16455154) [137548.125289] CPU2: Core temperature/speed normal [137548.125291] CPU3: Core temperature/speed normal [137847.287143] CPU2: Package temperature above threshold, cpu clock throttled (total events = 17888019) [137847.287147] CPU3: Package temperature above threshold, cpu clock throttled (total events = 17888017) ... I'd like to turn this CPU to power-saving mode, or choose the frequency, like with good old cpufreq powersave or userpace cpufreq governors. I wonder, what manual throttling method would work on these CPUs..

If I run indicator-cpufreq in the console it will start up just like it is supposed to and appear in the panel. However, if I place the same command in the startup programs it doesn't appear on login. I'm using Mint Linux and the Cinnamon desktop. How can I run this program on login?

On my machine, i have power savings disable on the BIOS. When I run Ubuntu on this machine, the CPU's are running maximum at 2100 MHz. However, when I'm running CentOS 7, even with the scaling governor set to "performance", the CPU's are not running full at 2100 MHz. cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor performance performance performance performance grep -i mhz /proc/cpuinfo cpu MHz : 1688.285 cpu MHz : 2058.656 cpu MHz : 1622.988 cpu MHz : 2070.632 My application is a network processing application, so the CPU clock difference is resulting a performance difference. I do not have cpuspeed,powerd, or any other power regulating services running. So my question is, is this expected behavior given the cpupower is set to "perform"? It seems CentOS is override the BIOS setting. When I boot to Ubuntu, it just takes the BIOS settings and all the CPU's are running max.

My /proc/cpuinfo says my processor is 800Mhz, when I know the thing is actually 2.8Ghz. This is due to idle throttling where the cpu clock is slowed when idle to save power. Is there a way in Linux to find the **true** cpu speed?

I am running a system with RT-Preempt kernel v6.4.8-rt8 CPU is 12th Gen Intel(R) Core(TM) i7-12800HE This system is receiving data through the CAN Bus. Every 1 millisecond a burst of 3 messages is received in the hardware CAN interface. Most of the time (99.99998%) of the time the messages are available on the socket to be received within 1ms of the previous group. But once per minute approximately, there is a delay of 4-6 ms in which the messages has been received in the hardware but is not available on the socket when calling recv. Things I have checked: - My application is calling deterministically recv every 1ms, the data is not there. - With candump I get the confirmation that the messages are received every 1 ms by checking the hardware timestamp. - The IRQ associated with the CAN device is bound to a CPU core (2) that is not used by my RT application (CPU core 6) ## The hack If I execute stress --cpu 1 and bind the stress CPU core to the same core as the IRQ the delays disappear. So I assume that a delay in waking up the CPU is causing the culprit. I have tried all of the following to try to keep the CPU awake without using stress. - performance /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor - performance /sys/devices/system/cpu/cpu2/cpufreq/energy_performance_preference - idle=poll intel_idle.max_cstate=0 in /etc/default/grub and update-grub; reboot Still have delays with all these applied. I am out of ideas, I cannot switch to acpi-cpufreq because it does not respect the integrated GPU power consumption (which is not being used during these tests). Any other knobs I can turn to decrease that latency or ways I can understand the root issue?

**Edit:** The original question of this post was regarding the "average" cpu MHz as obtained via conky builtins and the command line. A further question was regarding temperatures as reported by conky vs temperatures obtained via the command line. A tertiary question was regarding per core MHz as reported by both methods. 1. The "average" MHz question has been rendered superfluous by my discovery that I'd messed up my conkey.conf file a very long time ago. There is no average cpu MHz variable in the current version of conky, and there might not have ever been. In addition. it's such a transitory measurement, I'm not sure it's actually useful at all - at least for me. 2. @terdon requested a minimal conkyrc file so other people could try to reproduce what I said I was experiencing. So I created one. I'll include it below. But creating it allowed me to see I was seeing what I expected to see - not what was actually there. It turns out that the command I had been using to get the cpu temp - ${hwmon 1 temp 3}, actually is the cpu die teperature plus the Tctl offset for fan control. The actual cpu temp can be obtained with this command: ${exec sensors -f k10temp-pci-00c3 | grep Tccd1 | cut -b 15-21}F. I don't see a way to get the actual cpu temp through conky's builtins. 3. The per core MHz question as reported by conky's builtins, and the command line. This question is still out there, but I think I know whats going, I just haven't proved it yet. At least to myself. I created the requested conky.conf - I don't use a conkyrc file. And running it next to my actual conky was giving me really interesting results. So I created another version, identical to the other, but one being aligned to the middle_left, and the other being aligned to the middle_middle. In these conky.conf files, I'm using both the builtins, and getting the stats from an exec command. Interestingly, all 4 sets of data from these two conky instances will often align very well. Sometimes almost perfectly! That was actually surprising. And the data being reported from my actual conky was almost always in the 3-4 GHz range, while the two test conky's was almost always in the 2 GHz range... So, what I think is going on is my 'production' conky.conf is rather large - with lots and lots going on. and it kicks up the cpu frequency while it's running. And then when the test conky.confs are running, they show lower GHz because they're actually being less demanding. Does this sound reasonable? Here's the test conky.conf: conky.config = { alignment = 'middle_left', background = false, update_interval = 1.5, cpu_avg_samples = 2, out_to_console = false, override_utf8_locale = true, double_buffer = true, text_buffer_size = 8192, own_window = true, own_window_transparent = true, own_window_argb_visual = true, own_window_type = 'normal', own_window_argb_value = 0, own_window_hints = 'undecorated,below,sticky,skip_taskbar,skip_pager', border_inner_margin = 20, border_outer_margin = 0, font = 'monospace:size=10', gap_x = 350, gap_y = 0, minimum_width = 450, minimum_height = 450, draw_borders = false, use_xft = true, xftalpha = 0.8, uppercase = false, maximum_width = 1024, temperature_unit = "fahrenheit", } conky.text = [[ CPU Temp: Conky Builtin 1 3: ${hwmon 1 temp 3}°F Using hwmon: ${exec awk '{print ((($0 / 1000)*1.8)+32) }' < /sys/class/hwmon/hwmon1/temp3_input }°F # Temp of the die plus the Tctl offset for fan control Using sensors Tctl : ${exec sensors -f k10temp-pci-00c3 | grep Tctl | cut -b 15-21}F # Temp of the die itself Using sensors Tccd1: ${exec sensors -f k10temp-pci-00c3 | grep Tccd1 | cut -b 15-21}F Average CPU Frequency: ${exec cat /proc/cpuinfo |grep "cpu MHz"| awk '{sum+=$4;} END{printf "%2.2f", (sum/12)/1000;}'} GHz CPU1: ${freq_g 1} GHz ${goto 170}CPU1: ${exec awk '{printf "%2.2f", ($0)/1000000;}' conky to gather, and display my Linux system stats for a long time. I noticed over a decade ago that the 'average' cpu MHz just copies the first core, it isn't an average of all cores. The command to get the average cpu frequency in conky is: ${freq_g 0}. To get the cores individually, you just use ${freq_g 1} - ${freq_g 12}. In other words, 0 is supposed to be the average, not the first core, and individually, you start counting at 1, through how many cores you have. But 0 and 1 both always display the exact same thing. Checking in bash, I run this command: grep "cpu MHz" corectrl to control the cpu governor, and control the gpu. When I set the cpu to 'performance mode', the frequency of the cpu jumps up accordingly - from the low 2 GHz range, to the low 4 GHz range, as reported by conky. But when I check the output with the above grep command, all the cores are showing that they're running in the low to mid 3 GHz range. I'm not really expecting precision numbers here, just pretty close ballpark numbers. Or, in other words, I expect precision numbers, but they're going to change so many time per second that I expect them to be reported differently. The biggest problem I'm having is that my grep command rarely shows the cpu frequency going above 4 GHz, while conky rarely shows it below 4 GHz - in performance mode. Should I just display the outputs from my grep command in conky, and just accept the two outputs aren't going to jive? ---- I'm having a very similar issue with conky's built in cpu temperature detection. I can display what conky's builtin is reporting, and the results using sensors, and hwmon. The conky builtin is almost always showing the lowest temperature. The other two methods bounce around a lot more, and usually show higher temperatures then conky's builtin. And I mean they might show a ten degree difference, or more, for a long time.

The new pstate Intel driver pisses me off for good, because they have removed the good old powersave governor that allowed me to set the lowest available CPU frequency and run my numerical simulations for hours or days in a nicely silent, cold laptop. To make things worse, what they call now powersave is essentially the old governor ondemand, i.e. a mode in which the CPU frequency rams up with the load, and with it the damn fan noise: > Since these policies are implemented in the driver, they are not same as the cpufreq scaling governors implementation, even if they have the same name in the cpufreq sysfs (scaling_governors). For example the "performance" policy is similar to cpufreq(TM) "performance" governor, but "powersave" is completely different than the cpufreq "powersave" governor. The strategy here is similar to cpufreq "ondemand", where the requested P-State is related to the system load. (Extracted from https://www.kernel.org/doc/Documentation/cpu-freq/intel-pstate.txt) Now, please, is there any other way to keep my CPU frequency at a minimum? It's really important for me. I just prefer to dump the laptop through the window if I eventually cannot set a constant, lowest CPU frequency. That is how I use my laptop and that is what I want a laptop for, and I have been trying to achieve this for several days already! I'm trying this, and it doesn't work: echo 42 | sudo dd of=/sys/devices/system/cpu/intel_pstate/max_pref_pct to set the maximum speed at 42%, and it doesn't have any affect, the CPU keeps on going to 100% whenever I do something. What am I doing wrong? (should I restart some service or something?) Is there any way to get this? Also, will a non-Intel CPU allow me to do that? I don't mind buying another laptop it that is going to solve the problem.

Following an upgrade (or a reboot) on a Debian testing, I noticed that my system was much slower than usual. The CPUs seem to be systematically scaled down. I used cpupower to ensure that the performance governor was used:

analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 10.0 us
  hardware limits: 400 MHz - 2.70 GHz
  available frequency steps:  2.70 GHz, 2.70 GHz, 2.60 GHz, 2.50 GHz, 2.40 GHz, 2.30 GHz, 2.20 GHz, 2.10 GHz, 2.00 GHz, 1.90 GHz, 1.80 GHz, 1.70 GHz, 1.60 GHz, 1.50 GHz, 1.40 GHz, 1.30 GHz, 1.20 GHz, 1.10 GHz, 1000 MHz, 900 MHz, 800 MHz, 700 MHz, 600 MHz, 500 MHz, 400 MHz
  available cpufreq governors: userspace performance schedutil
  current policy: frequency should be within 2.70 GHz and 2.70 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: 2.70 GHz (asserted by call to hardware)
  boost state support:
    Supported: yes
    Active: yes

However despite what is claimed, the CPU is not running at 2.7 GHz. Here is the result of turbostat --Summary --quiet --show Busy%,Bzy_MHz,Avg_MHz --interval 1 with a running Firefox and VLC:

Avg_MHz Busy%   Bzy_MHz
92      18.59   494
59      12.64   469
52      10.11   512
164     37.58   438
184     43.01   429
261     56.64   458
225     44.50   505
244     45.91   534

The CPUs are quite busy but running at a slow frequency. I tried to stress the CPU with a CPU-intensive program: I launched xz -T 10 on a huge file. Here is the output of turbostat when xz was running:

493     98.71   499
497     99.77   498
496     99.61   498
497     99.35   500
495     99.38   498
489     99.76   490
489     99.70   493

We see that the CPU is fully used but still running at a low frequency. In the meantime, using sensors I can see that the temperature of the CPU looks normal:

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +53.0°C  (high = +100.0°C, crit = +100.0°C)
Core 0:        +46.0°C  (high = +100.0°C, crit = +100.0°C)
Core 4:        +47.0°C  (high = +100.0°C, crit = +100.0°C)
Core 8:        +51.0°C  (high = +100.0°C, crit = +100.0°C)
Core 9:        +51.0°C  (high = +100.0°C, crit = +100.0°C)
Core 10:       +51.0°C  (high = +100.0°C, crit = +100.0°C)
Core 11:       +51.0°C  (high = +100.0°C, crit = +100.0°C)
Core 12:       +49.0°C  (high = +100.0°C, crit = +100.0°C)
Core 13:       +49.0°C  (high = +100.0°C, crit = +100.0°C)
Core 14:       +50.0°C  (high = +100.0°C, crit = +100.0°C)
Core 15:       +50.0°C  (high = +100.0°C, crit = +100.0°C)

Thus the CPU throttling doesn't seem to be caused by a high temperature. What could be causing this and how could I change the setting? Thanks a lot!

As CPU clock can be limited by thermal thesholds (implemented by CPU vendor firmware / controller or in Linux by /sys/devices/virtual/thermal/cooling_device* devices), is it also possible to limit by temperature gradient over time? Eg. when system leaves standby in cold environment, set the clock limits to slowly (over some seconds or minutes) rise core and heatsink temperature, reducing thermal cycling stress?

Running sudo cpupower monitor on Ubuntu 24.04 I'm getting:

| Nehalem                   || Mperf              || RAPL               || Idle_Stats
 CPU| C3   | C6   | PC3  | PC6   || C0   | Cx   | Freq  || pack | core | unco  || POLL | C1_A | C2_A | C3_A
   0|  0.00|  0.46|  0.00|  0.00|| 11.71| 88.29|  3060||37496059|27532217| 73852||  0.01|  8.94| 79.93|  0.00
   1|  0.00|  0.46|  0.00|  0.00||  6.56| 93.44|  2790||37496059|27532217| 73852||  0.00|  2.56| 53.19| 37.97
   2|  0.00|  4.67|  0.00|  0.00||  9.14| 90.86|  3194||37496059|27532217| 73852||  0.01|  4.43| 58.09| 28.77
   3|  0.00|  4.67|  0.00|  0.00||  6.24| 93.76|  3239||37496059|27532217| 73852||  0.00|  1.69| 34.62| 57.66
   4|  0.00|  0.00|  0.00|  0.00||  0.29| 99.71|  4461||37496059|27532217| 73852||  0.00|  0.00|  0.00| 99.97
   5|  0.00|  0.00|  0.00|  0.00|| 29.52| 70.48|  4457||37496059|27532217| 73852||  0.00| 64.48|  0.00|  6.48
   6|  0.00|  0.00|  0.00|  0.00|| 47.92| 52.08|  4123||37496059|27532217| 73852||  0.00|  0.95|  0.31| 51.40
   7|  0.00|  0.00|  0.00|  0.00||  0.00|100.00|  3753||37496059|27532217| 73852||  0.00|  0.00|  0.00| 99.99
   8|  0.00| 25.03|  0.00|  0.00||  3.27| 96.73|  2807||37496059|27532217| 73852||  0.01|  4.13| 54.72| 38.03
   9|  0.00| 62.12|  0.00|  0.00||  2.32| 97.68|  2897||37496059|27532217| 73852||  0.00|  1.29| 30.79| 65.69
  10|  0.00| 77.85|  0.00|  0.00||  2.19| 97.81|  3064||37496059|27532217| 73852||  0.00|  0.94| 18.42| 78.51
  11|  0.00|  0.00|  0.00|  0.00|| 14.84| 85.16|  2497||37496059|27532217| 73852||  0.01| 57.88| 27.45|  0.38
  12|  0.00| 70.55|  0.00|  0.00||  3.27| 96.73|  2399||37496059|27532217| 73852||  0.00|  1.33| 30.14| 65.41
  13|  0.00| 54.45|  0.00|  0.00||  4.02| 95.98|  2213||37496059|27532217| 73852||  0.00|  1.06| 43.49| 51.62
  14|  0.00| 67.90|  0.00|  0.00||  3.36| 96.64|  2334||37496059|27532217| 73852||  0.00|  1.34| 30.91| 64.54
  15|  0.00| 72.39|  0.00|  0.00||  2.41| 97.59|  2167||37496059|27532217| 73852||  0.00|  1.25| 26.74| 69.73

What is the meaning of columns in this table? cpupower manual (https://linux.die.net/man/1/cpupower-monitor) doesn't have that information. I'm assuming that C3, C6, etc. are percentages of time spent in a given CPU C-state. Also, I'm running a program with two threads pinned to CPU #5 and #6. Cores #2 and #3 containing hyperthreaded CPUs 4-7 are isolated with GRUB_CMDLINE_LINUX="nohz=on nohz_full=4-7 rcu_nocbs=4-7 isolcpus=4-7 irqaffinity=0-3,8-15". The table above confirms load on CPU #5 and #6, but also consistently shows some marginal load on CPU #4. It doesn't correspond to the screen of Ubuntu System Monitor, which consistently shows 0% load on CPU #4 listed as CPU5 here: Additionally, why logical CPUs of the same physical core show different frequencies?

After disabling **intel_pstate** driver, I get the following error:

cpupower frequency-info
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  CPUs which run at the same hardware frequency: Not Available
  CPUs which need to have their frequency coordinated by software: Not Available
  maximum transition latency:  Cannot determine or is not supported.
Not Available
  available cpufreq governors: Not Available
  Unable to determine current policy
  current CPU frequency: Unable to call hardware
  current CPU frequency:  Unable to call to kernel
  boost state support:
    Supported: yes
    Active: yes

I would like to use the **acpi-cpufreq** module instead, in order to have the governor userspace available and set specific CPU frequencies.

Looking at the intel_pstate kernel documentation, apparently hwp_dynamic_boost should dynamically increase performance when a task waiting on IO is selected to run. Enabling this feature will not allow me to change the energy performance preference while the governor is set to performance. If the governor is set to powersave I *can* change the EPP. Which raises the question: What is HWP dynamic boost supposed to do? When enabled it either maxes out the EPP or doesn't do anything depending on the value of the governor. Also I couldn't notice any dynamic p-state switching. Each CPU just locks at a set EPP and never changes no matter how much I keep monitoring each core even under load (maybe it happens inside the CPU and unrelated to the scaling driver?). All synthetic benchmarks with or without dynamic boost seem within margin of error with RAPL reporting the same power consumption. I know that according to the documentation it should change when an IO task resumes and not under 100% load but I just don't know how to test that. Testing how "smooth" the device feels is also not possible for me as my CPU is quite overkill and any small changes on non full loads are barely noticeable. So I thought it would be easier just to ask whether someone already knows the functionality behind this feature, how does it impact power consumption and how to leverage it in order to optimize power to performance balance in my device.

I'm running some benchmarks on my Linux desktop/laptop computer, but I'm not getting reliable results. I'm running a CPU-intensive task that does negligible I/O and doesn't use much RAM. My computer is multicore and not doing much. So I expect only slight variations between runs. But I see huge variations.

$ bash -c 'x=0; time while ((x < 999999)); do ((++x)); done'

real    0m2.281s
user    0m2.279s
sys     0m0.001s
$ bash -c 'x=0; time while ((x < 999999)); do ((++x)); done'

real    0m0.906s
user    0m0.906s
sys     0m0.000s
$ bash -c 'x=0; time while ((x < 999999)); do ((++x)); done'

real    0m1.030s
user    0m1.030s
sys     0m0.000s

There seems to be a cluster of fast times and a cluster of slow times, with the occasional thing in between. The variability between fast times is small enough for my purposes, and the variability between slow times is small enough for my purposes. But I can't work reliably when I don't know if I'm getting a slow time or a fast time or an in-between time. The variability is in user time, and the real time is almost equal to the user time (it's a single-threaded task). So the problem isn't that some other process is sharing the CPU. What's going on, and how can I get reliable benchmarks for a CPU-bound task on my PC?

When I do

sudo watch -n1 cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq

I get 1.8 - 2.7 GHz. It never goes above 2.7. And when I do

watch -n1 "cat /proc/cpuinfo | grep MHz"

I get 768 MHz - 1.8 GHz. It never goes above 1.8. Anyone know what is going on?

In theory, switching from the ondemand governor to conservative should save battery life on laptops. However, I don't think I've *ever* seen any tests done to verify this or show how significant a saving can be made. Can anyone find a source where such tests have been done?

I'm on a Dell laptop with Sandy Bridge Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz CPU running a 5.15.0-100-generic Linux kernel. The CPU goes up to 3.4GHz (as both the MATE CPU Frequency Monitor applet shows and as /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq shows) and it seems to get stuck at a lower frequency whenever the temperatures reach a certain threshold. Then it won't go up to 3.4GHz again unless both the temperature decreases (putting the laptop in the freezer for a bit helps in that regard) and the computer is rebooted. Is there any way to force it back up without at least the reboot step? I have my MATE CPU Frequency Monitor set to Performance and I've tried sudo cpufreq-set -g performance, and writing 3400000 to /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_min_freq (seemed like it could do it) but none work other than both decreasing the temperature (that alone won't make the frequency go back up) and rebooting (that alone doesn't work either unless the temperature is low at the time of reboot). I care because the lower frequenciese mess up my microbenchmarks.

I am currently facing a problem with my Lenovo E15 laptop (AMD Ryzen 5500u "Lucienne" processor) and the kernel 6.5. (Xubuntu 22.04) Maybe three weeks ago, I noticed that my computer was having a laggy behaviour, applications were slow, Wi-Fi had hiccups where it took many seconds to respond, and of course internet surfing was awful. I was looking for a cause for all this, and I finally discovered that the CPU governors had changed. Before, I mainly used two governors on this computer: - Ondemand: most of the time I use this governor. It uses the good CPU clock for the need (1.4 GHz lowest) - powersave: when I play 2D games on the computer, I use this governor to reduce heating and vents as they were fluid at 1.4 GHz. And the new ones: - powersave: seems to behave like ondemand governor before but reduces the clock even more (0.4 GHz lowest) - performance: max out the CPU clock (4.0 GHz?) I thought that there was a bug in the kernel, so I decided to update it with mainline software, but the newest kernel (6.7.8 ?) has the same problem. When I switch back to 6.2 kernel (exactly 6.2.0-39.40~22.04.1), the problems disappear.  This is what I do for the moment, but Ubuntu 24.04 is pointing out and will I be able to keep 6.2 kernel with it? What other things I could test?

I'm using a Raspberry Pi board and I would like to build a real time system. During the kernel configuration, I found the **CONFIG_CPU_FREQ** option, which (from the help section) > allows you to change the clock speed of the CPU on the fly. This is a > nice method to save power, because the lower the CPU clock speed, the > less power the CPU consumes. That's a nice approach to consume less power but in real time applications this could lead to unpredictable behavior and high latencies. Xenomai developers suggest to disable **CONFIG_CPU_IDLE** because (from here ) > it allows the CPU to enter deep sleep states, increasing the time it > takes to get out of these sleep states, hence the latency of an idle > system. Also, on some CPU, entering these deep sleep states causes the > timers used by Xenomai to stop functioning I was wondering if disabling these two options could damage the cpu since the board does not come with a heat dissipation system? I imagine that, without these options, the cpu will be more reactive but it sounds like a CPU-Seppuku to me.