We have a small cluster where I work, that I look after. The nodes run CentOS 7.5.
Our older nodes use Xeon E5 v4 CPUs, mostly the E5-2699 v4. With the older nodes, the Intel Turbo Boost works properly, and individual cores of the CPU are free to ramp all the way up to the Max Turbo Frequency, as specified in the CPU's specs.
The problem is with our newer systems. Most of them are equipped with Xeon Gold 6152 CPUs. They will only ramp up to the base frequency (2.1 GHz), and never go above that. The lscpu command also indicates that this is the maximum speed of the CPU, while it should be indicating that the maximum is 3.7 GHz (Maximum Turbo).
I suspect the problem has to do with the speed control driver.
On the older systems, the command cpupower frequency-info indicates that the driver is "intel_pstate".
However, on the newer systems, that command indicates that the driver is "acpi-cpufreq". This strikes me as "the default driver for CPU speed control when the specialized one won't work."
From the research I have done thus far, I have learned that acpi-cpufreq is a kernel module, while intel_pstate appearss to be part of the kernel.
What can be done to get our newer systems speed controlling properly, to get full access to their specified maximum turbo speeds?
We have already checked that turbo is enabled in the BIOS settings.
(We are also having the same issue with our ATOM C3955 Processors.)
Best Answer
Got it resolved, at least in preliminary testing.
As suggested by @silmaril and @Michael Hampton, the issue was the Kernel. I updated it to 4.19.8-1.el7.elrepo.x86_64, and now the Xeon Gold 6152 CPU based system I tried it on is now reporting the correct 3.7 GHz as the CPU max speed. It is also reporting that the frequency control driver is now "intel_pstate".
I followed instructions from this article, which basically has you add a repo from ELRepo (who compile newer Kernels and other things for CentOS/RHEL), then download and install the newest Kernel they have.
EDIT: I have now also tested this against the ATOM C3955 based systems we also have here. Results were a bit more ... dubious. Checking with commands like
lscpuandcpupowerseem to indicate that the CPU is still stuck with the max speed being at the base clock speed. However, while running under heavy load the cpu clock speeds will show at (or near) the CPU's max turbo using the commandwatch -n.1 'cat /proc/cpuinfo | grep -i mhz'. So it works, but not perfectly.