For Centos/RHEL prior to 7.0 we used to modify the kernel entry in the /etc/grub.conf file by appending the following to the kernel command:
intel_idle.max_cstate=0 processor.max_cstate=0
However, for Centos and RHEL 7.2 and higher
We might need to add the following to the end of the grub:
intel_idle.max_cstate=0 processor.max_cstate=1 intel_pstate=disable
and not
nosoftlockup intel_idle.max_cstate=0 mce=ignore_ce
as per https://my.vertica.com/kb/Configuring-the-HPE-Proliant-DL380-Gen9-24-SFF-CTO-Server-as-a/Content/Hardware/Configuring-the-HPE-Proliant-DL380-Gen9-24-SFF-CTO-Server-as-a.htm
Background from https://access.redhat.com/solutions/2895271
Maximum CPU frequency is no maintained even though
• Either tuned profiles with maximum performance are set (throughput-performance, latency-performance)
• Or
o tuned is disabled and having grub set with: intel_idle.max_cstate=0 processor.max_cstate=1 AND
o Server is set to maximum performance in BIOS
Resolution
• Disable tuned
• add the following to the end of the grub command line:
intel_idle.max_cstate=0 processor.max_cstate=1 intel_pstate=disable
Root Cause
In Nehalem ("no version") and Ivy Bridge (V2) processors, p-states were managed by a simple algorithm that allowed a user to request a value from a preselected list of values.
The preselected values are a list of discrete values provided by the hardware to the acpi-cpufreq driver.
For example, the acpi-cpufreq driver might show frequencies of 2200MHz, 2100MHz, 2000MHz, 1500MHz, 1200MHz, 800MHz.
Each of these specific frequencies can be selected by the user, and the system is guaranteed to respond with that frequency.
Starting with some models of Haswell (V3), and continuing with Broadwell (V4), p-states were handled with a new driver, called the intel-pstate driver.
This driver used a discrete mechanism by which you could request and receive a specific cpu frequency.
For example, the intel-pstate driver might show a maximum frequency of 2200MHz, and a minimum frequency of 1200MHz.
Any value in that range could be requested (for example, 1983MHz) and that frequency would be guaranteed.
Starting with some later models of Broadwell (V4) and Skylake (V5), Intel introduced a mechanism called Hardware P-States (HWP).
The behaviour of HWP is similar to that of Haswell (V3), and early Broadwell (V4), except that the returned frequency of the cpu is no longer guaranteed.
This is because HWP uses hardware information to determine the "best" frequency for the cpus.
For example, if a user requested 800MHz, the hardware using system temperature information may determine that a better frequency for the workload is really 900MHz and will raise the frequencies temporarily to that value.
Similarly the hardware can choose to drop the frequency of a cpu (or several cpus) in order to prevent overheating issues.
The above HWP model means that at both low end and high end frequencies the frequency returned by the processor is no longer guaranteed to be the requested frequency.
