Showing results for 
Search instead for 
Did you mean: 

is intel_pstate working with or without HWP?


I wonder IF intel_pstate is working in active_mode with OR without HWP enabled? I believe the processor supports HWP because as I can see 4 HWP flags when I cat /proc/cpuinfo. Namely I can see:

  • hwp
  • hwp_act_window
  • hwp_epp
  • hwp_pkg_req

From the guide - section energy-vs-performance-hints I can read that:

If intel_pstate works in the active mode with the HWP feature enabled in the processor, additional attributes are present in every CPUFreq policy directory in sysfs

But those attributes (energy_performance_preference and energy_performance_available_preferences) are not present in sysfs.

On the other hand, the scaling_driver attribute has the value intel_pstate, so once again by guide - section active-mode I can assume intel_pstate is set in active mode.

This is the default operation mode of intel_pstate. If it works in this mode, the scaling_driver policy attribute in sysfs for all CPUFreq policies contains the string “intel_pstate”.

I find it a bit awkward that intel_state is not using HWP, since it is the default behavior and that there are no kernel parameters telling him to do otherwise. And why are the energy_preference parameters not available in sysfs?

The attribute status which could give a hint is also not present in /sys/devices/system/cpu/intel_pstate/  (see guide - section global attributes)

I am not an expert on the subject and that's why I post this question.

This same behavior is observed in two different machines with the following CPU's - Xeon(R) Gold 6154, Core(TM) i7-6700HQ

Thanks for any help!




0 Kudos
4 Replies
Black Belt

The behavior probably depends on the kernel version (as well as the BIOS).  If I recall correctly, with the CentOS 7.4 and 7.6 releases (3.10 kernels with backports) the default behavior of intel_pstate is ignore HWP if the BIOS has not disabled it.  This allows the user to enable it later, if desired.   The last time I checked there were numerous bugs in the sysfs drivers (e.g., incorrect computation of frequency scaling values, failure to update values across different control mechanisms, etc), so I wrote my own tool to read/write the enable HWP and set the HWP MSRs directly. 

I saw a note in the 4.4 kernel discussions that mentioned changing the default behavior to enabling HWP, but I have not used any kernels that new.


Thanks for your reply. My delay on this response was due to having access to BIOS parameters.

Bellow are the BIOS parameters for my system regarding the processor unit. I do not see any configuration that might be disabling HWP on my system :

    Processors.UPILinkDisable=Enable All Links
    Processors.SnoopPreference=Home Snoop Plus
    Processors.UPILinkFrequency=Max Performance
    Processors.CPUFrequencyLimits=Full turbo uplift

My kernel is 4.9.0. AFAIK, HWP is the default method since kernel 4.6-rc1 (see commit
Having no kernel options that could disable HWP (like intel_pstate=no_hwp) and neither BIOS options conflicting with HWP usage, I'me forced to admit that it must enabled. I have no evidence of otherwise.

It would be great to have method that could hint on the HWP usage. Like tweaking sysfs parameters and watching for system response. But I only have the following attributes under intel_pstate directory and I'm not sure what kind of tweak I could do that would reveal HWP behaviour - max_perf_pct, min_perf_pct, no_turbo, num_pstates and turbo_pct.

Regading the driver modus operandi I'm not sure I quite understand it's behaviour when HWP is enabled.

In the docs it says in "active mode with HWP intel_pstate relies on the processor to select P-states by itself". Can I assume that in this case the govenors aren't used anymore? It also says that "What those hints are depends on which P-state selection algorithm has been applied to the given policy". But isn't this policy applied by the governor? I thought when I chose some governor that some very concrete policy (and algorithm) would be applied.

I see now that the words governor, policy and algorithm can be tricky. So, the governor is not used to chose the p-states, but it's still used to define a policy? Which then will hint the processor on how to chose it's own p-states? I think I've got it!

If it's not to abuse, can I ask for the difference between the this two attributes? Is there any? Why there are two different attributes if they have the same info? - scaling_cur_freq and cpuinfo_cur_freq

Thanks for your help.


Black Belt

The option "Processors.CPUPstateControl=Cooperative" might be related to HWP capabilities....

CPUID leaf 0x06 provides information about whether HWP is supported (i.e., has not been disabled by the BIOS).   Most of my systems show that HWP is *not* supported (%eax bit 7 is clear) because the BIOS has full control of the frequency.   Enabling a BIOS option with a description along the lines of "OS frequency control" results in HWP being reported as available by CPUID.  Once CPUID reports HWP as available, MSR 0x770 can be read and if it is zero, bit 0 can be written to enable HWP.  Then I control frequency by writing the desired minimum and maximum core clock ratios to MSR 0x774 (IA32_HWP_REQUEST) on each logical processor.   This controls the frequency (subject to max Turbo frequencies and power limits) while the core is active, but does not prevent the HW from dropping the frequency to the "maximum efficiency frequency" (typically 1.0 GHz on SKX/CLX Xeon) while in core C1E state.

The Linux governors can use HWP, but in my experience they don't do it correctly in the CentOS 7 kernels (3.10.x).  I gave up trying to keep track of the bugs -- especially after seeing that there is no "userspace" governor available with HWP enabled (at least in the kernel levels that I have been working with).


Thank you very much for your help.