How to limit CPU frequency at early boot?

[Debian_SuperUser]

I am on a machine that has a hardware problem, and the only workaround is to limit the CPU frequency by a little. On Ubuntu, I always keep the performance mode to power saver, so that it always boots at 800 MHz, and then I can increase it using cpupower. But what I have noticed is that in the early boot (presumably before even loading systemd), my CPU frequency may not be limited as the power saver governer might not have been loaded, and sometimes it does crash because of it. Is there possibly like any Kernel parameter or any other way I can use to limit my CPU frequency?

Edit - Don't recommend me the firmware way, it is a laptop and OEMs are not that generous to keep such settings available.

 

[dos2unix]

Edit - Don't recommend me the firmware way, it is a laptop and OEMs are not that generous to keep such settings available.

As far as I know, that's the only way. There is no way for the software to do it, until the software is loaded. Which
can't be loaded until the OS is running.
Most of my newer computers don't have CPU throttling in the UEFI. Most of my really old ones allow me to disable
"Turbo boost" in the BIOS. Or at least limit CPU speed.

 

[Debian_SuperUser]

@dos2unix

Yes I can disable Turbo Boost in firmware, but unlike Throttlestop on Windows, there isn't a program that I know that can easily enable TB again at runtime. I would manually have to write to the MSR registers which I am not knowledgeable about.

Does the Kernel not have anything to limit the CPU performance? Disabling intel pstate doesn't actually limit the performance. I also see something related to ENERGY_PERF_BIAS on boot.

 

[dos2unix]

Does the Kernel not have anything to limit the CPU performance?

Yes, but we have the same chicken and egg problem.

In the Linux kernel, you can manage CPU performance scaling using the CPUFreq subsystem. Here are a few ways to limit CPU speed:

1. Scaling Governors and Drivers:
   • The CPUFreq subsystem consists of three layers: the core, scaling governors, and scaling drivers.
   • Scaling governors implement algorithms to estimate the required CPU capacity. Each governor typically implements a specific scaling algorithm.
   • Scaling drivers communicate with the hardware, providing information on available P-states (frequency/voltage configurations) and changing CPU P-states as requested by scaling governors1.
2. Setting Maximum and Minimum Frequencies:
   • Use the cpupower utility to set the maximum and minimum clock frequencies:
     • To set the maximum clock frequency: sudo cpupower frequency-set -u clock_freq
     • To set the minimum clock frequency: sudo cpupower frequency-set -d clock_freq
     • To set the CPU to run at a specified frequency: sudo cpupower frequency-set -f clock_freq2.
3. Kernel Compilation:
   • Compile the kernel and enable only the “powersave” governor. This sets the frequency statically to the lowest supported frequency by the CPU3.
4. CMD_LINE Parameter:
   • Specify the maximum performance percentage using the following command:
     echo "70" | sudo tee /sys/devices/system/cpu/intel_pstate/max_perf_pct
     https://stackoverflow.com/questions...-a-kernel-cmd-line-parameter-of-linux-on-boot
     (You can adjust the percentage based on your CPU’s clock speed and turbo speed; 70-80 should be sufficient to avoid exceeding 2.5 GHz)

The problem is you can't do any of this until the system is booted up.
You could possibly compile your own custom kernel, but then any system it was loaded on, could only
partially use the CPUs potential.

 

[Debian_SuperUser]

@dos2unix

Hmm. Well then do you know a way to enable Turbo Boost at runtime? Do you know any program? If not, then do you have any idea what MSR registers Throttlestop writes data to unlock TB? I think I had seen it somewhere in a post.

 

[dos2unix]

To access MSR registers, you can use the /dev/cpu/CPUNUM/msr device, where CPUNUM corresponds to the CPU number as listed in /proc/cpuinfo. The register access involves opening the file, seeking to the MSR number as an offset, and reading or writing data in 8-byte chunks

But even this... is after the OS is loaded. After the filesystem is mounted. So I don't see how it helps.

 

[Debian_SuperUser]

To access MSR registers, you can use the /dev/cpu/CPUNUM/msr device, where CPUNUM corresponds to the CPU number as listed in /proc/cpuinfo. The register access involves opening the file, seeking to the MSR number as an offset, and reading or writing data in 8-byte chunks

But even this... is after the OS is loaded. After the filesystem is mounted. So I don't see how it helps.

hmm. I only knew msr-tools to read and write to the registers.

 

[data_x33]

I am on a machine that has a hardware problem, and the only workaround is to limit the CPU frequency by a little.

Is it an Intel CPU?

 

[Debian_SuperUser]

Is it an Intel CPU?

i5 8350U

 

[data_x33]

i5 8350U

Does your notebook have a temperature issue? That solved the problem with my notebook.

Workaround for Intel throttling issues in Linux.

 

[Debian_SuperUser]

Does your notebook have a temperature issue? That solved the problem with my notebook.

Workaround for Intel throttling issues in Linux.

No, it has stability problems. It cannot handle the default 3.6 GHz turbo clock speed. Without hyperthreading, I can lock the frequency to about 3-3.1 GHz, and without hyperthreading, 3.4-3.5 GHz. But sometimes it can crash at boot because the governer that sets the frequencies is not loaded yet.

 

[osprey]

@Debian_SuperUser wrote:

But what I have noticed is that in the early boot (presumably before even loading systemd), my CPU frequency may not be limited as the power saver governer might not have been loaded, and sometimes it does crash because of it.
....
Does the Kernel not have anything to limit the CPU performance? Disabling intel pstate doesn't actually limit the performance. I also see something related to ENERGY_PERF_BIAS on boot.
....
But sometimes it can crash at boot because the governer that sets the frequencies is not loaded yet.

Some queries that arise for me in this case are the following:

Are there any statistical outputs to show that this high cpu frequency is actually the causal factor?
Or is this surmise?
Is there anything in the the boot.log, kernel.log or kernel ring buffer to indicate that this is actually the case?

The linux booting process typically is power efficient. What the process is doing at boot basically is initialising lots of hardware and loading drivers which are not tasks that require peak performance nor to be running at full power, but rather, at various levels closer to minimal power.

The boot processes are specifically designed in code to not generate a lot of heat, and that's to maintain stability. The demands on the cpu vary in the booting process in relation to the different tasks that it has to accomplish, so if there were peaks (which has not been established), they would be momentary in any case.

The sorts of tasks that really stress the cpu and have it working near maximum levels are things like compiling large codebases such as in technical use or scientific work which may require it, or large video processing activities.

The user can stress test the cpu to see how it behaves at very high levels of frequency by using stress tools designed for the purpose, or creating some intensely demanding processes that will achieve a similar state and be measurable shown in output data. In post #11 there are some stats, but no information on the particular tests or how they were implemented which would be useful for readers to know to have the issue clearer in making an assessment of the matter, and no evidence that this factor was implicated in the booting issue.

The cpu may simply not be in optimal or original condition and there simply may not be anything that can reasonably be done to ameliorate its state apart from measures already introduced to deal with its condition. The booting issue may or may not be affected by this, or there may be some other confounding variable which may or may not primarily implicate the cpu,

 

[Debian_SuperUser]

@osprey

You know, you don't have to take that much effort. I too have access to ChatGPT.

It is the frequency problem. No matter with or without load (unless running really low load like idle on Linux), it will crash if I let the frequency turbo to its max. Before that I suspected that it was a power problem, but sometimes even limiting the CPU power, it still crashed. Now, if I lock the CPU frequency down as I mentioned earlier, it won't crash no matter what.

Don't talk nonsense (actually its the AI I think but you used it), booting is Linux is not something very light. Sure it might not be as light as compiling the kernel, but it is relatively heavy and also it is optimized to use multiple threads and all and boot as fast as it can.

 

[osprey]

Actually it was cpu load documentation in the kernel docs that I consulted. Unfortunately the kernel doesn't provide stats for cpu activity in the earliest stages of booting. Hence there are difficulties in determining the extent of its work, but as mentioned, the design is to work closer to minimal levels than maximum. There are many variables inside the cpu itself, voltages, L caches, registers etc any of which may be implicated or not. It doesn't seem as if it's going to be a problem that can be worked out without specific cpu tools such those used by the manufacturers. The user's workarounds may suffice to have the unit functioning, but that's not really explanatory of the problem which appears to be what you are after. The conjecture that the style of writing in post #12 derives from AI is mistaken, however flattering.

 

[data_x33]

No, it has stability problems. It cannot handle the default 3.6 GHz turbo clock speed. Without hyperthreading, I can lock the frequency to about 3-3.1 GHz, and without hyperthreading, 3.4-3.5 GHz. But sometimes it can crash at boot because the governer that sets the frequencies is not loaded yet.

I created a script that logs the CPu-speed during boot. It starts after "apparmor.service" and before "netfilter-persistent.service". I suspect that turbomode is already active during boot. My Intel i5 CPU runs max 2.5GHz without turbomode and max 3.1GHz with turbomode. Here are the log entries:

$ cat pstate-info.log
Starting pstate-Info logging
---------------------
pstate Configuration:
active
---------------------
2024-06-16 12:02:08 | CPU MHz: 2899.999
2024-06-16 12:02:09 | CPU MHz: 562.403
2024-06-16 12:02:10 | CPU MHz: 399.989
2024-06-16 12:02:11 | CPU MHz: 400.022
2024-06-16 12:02:12 | CPU MHz: 400.000
2024-06-16 12:02:13 | CPU MHz: 852.425
2024-06-16 12:02:14 | CPU MHz: 2325.216
2024-06-16 12:02:15 | CPU MHz: 400.000
2024-06-16 12:02:16 | CPU MHz: 2799.995
2024-06-16 12:02:17 | CPU MHz: 399.995
2024-06-16 12:02:18 | CPU MHz: 2800.798
2024-06-16 12:02:19 | CPU MHz: 2931.766
2024-06-16 12:02:20 | CPU MHz: 2800.005
2024-06-16 12:02:21 | CPU MHz: 2900.004
2024-06-16 12:02:22 | CPU MHz: 2800.000
2024-06-16 12:02:23 | CPU MHz: 2199.995

 

[data_x33]

You could write a systemd rule to disable turbomode shortly after sysinit.target and basic.target. Whether this will solve your hardware problem remains to be seen.

 

[Debian_SuperUser]

You could write a systemd rule to disable turbomode shortly after sysinit.target and basic.target. Whether this will solve your hardware problem remains to be seen.

What is "turbo mode"?

 

[data_x33]

What is "turbo mode"?

Sorry, I meant turboboost.

 

[Debian_SuperUser]

Sorry, I meant turboboost.

I can only disable TB in firmware, and then I can't enable it in Linux. However there are programs on Windows which let me do this and this is how I do it. I think there too, the power profile which I have edited which has the frequency lock (its a hidden setting) isn't loaded early in the boot and with TB enabled, Windows also does crash. But there I can at least enable TB dynamically even if locked in firmware. No program like this exists on Linux. I manually would have to write to the MSR registers.

 

[data_x33]

I can only disable TB in firmware, and then I can't enable it in Linux. However there are programs on Windows which let me do this and this is how I do it. I think there too, the power profile which I have edited which has the frequency lock (its a hidden setting) isn't loaded early in the boot and with TB enabled, Windows also does crash. But there I can at least enable TB dynamically even if locked in firmware. No program like this exists on Linux. I manually would have to write to the MSR registers.

You can't use the msr-tools (wrmsr) until sysinit.target has been loaded.

Unfortunately, there is no program/tool to accomplish this. You have to do it with scripts.