How can I get my CPU to run at maximum speed by circumventing CPU scaling? [closed]

I am running CentOS 7 (7.9.2009) (kernel 3.10.0-1160.49.1.el7.x86_64) on a rather old laptop (Lenove T61) with a dual core CPU (Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz). The driver for CPU scaling is acpi-cpufreq, and when on the performance governor, I can get the CPU to run at the max CPU speed as listed in /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq, and observe this by doing:

$ grep -i mhz /proc/cpuinfo 
cpu MHz     : 2001.000
cpu MHz     : 2001.000

and it is rock-steady at this speed. I can verify this by doing:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
2001000
$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq 
2001000

I am trying to run at a constant frequency for a real-time program that counts CPU clock cycles for timing. I compiled a custom kernel (5.10.83-rt58) to support a piece of hardware that isn't supported in the default CentOS kernel (3.10.0). CPU scaling usually causes the clock frequency to jump around, but I found that I can get a steady frequency by setting all the values in /sys/devices/system/cpu/cpu*/cpuidle/state*/disable to 1. When I check the frequency:

$ grep -i mhz /proc/cpuinfo 
cpu MHz     : 1995.106
cpu MHz     : 1995.106

it is not quite at the 2001MHz as seen with the 3.10.0 kernel. The following command verifies this:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1995106

But the output of:

$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
2001000

is different. My question is does anyone know why my CPU isn't running at the maximum frequency (2001MHz) but at ~6MHz less? Did something drastic change in cpu scaling between kernel 3.10 and 5.10?

I am trying to run at a constant frequency for a real-time program that counts CPU clock cycles for timing.

This approach is problematic, as modern performance scaling CPUs are not going to run at one frequency. Their exact cycle count depends on thermal conditions. Maybe your socket is ever so slightly defective. And your custom kernel could have arbitrary differences from Red Hat's so yes it is possible it (or the microcode) pokes the CPU in different ways.

Use the timer APIs provided. Linux realtime outlines a basic cyclic application. Note the use of clock_nanosleep() with CLOCK_MONOTONIC.

ESR's time programming reference is a decent history of why there are several dozen time functions.

To tweak CPU governors and other tuning for latency and power reasons, have a look at tuned. For example, the latency-performance profile.