| Message ID | 20240624161109.1427640-1-srinivas.pandruvada@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Update highest frequency of a CPU after boot | expand |
On Mon, Jun 24, 2024 at 6:11 PM Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> wrote: > > Intel Xeon servers, which are capable of dynamic highest performance > change, are unable to achieve the highest frequency when the performance > profile is changed. > > The highest frequency at which a CPU can operate is not fixed and can > vary after the system boots. These changes can be initiated by switching > to different performance profiles using the Intel Speed Select Technology > interface. Additionally, adjustments can be made remotely through a BMC > (Baseboard Management Controller) interface. Administrators can select > various performance profiles to align with specific performance > requirements, as these choices will directly influence the total power > consumption and cooling requirements. > > Whenever an administrator switches to a different performance profile that > alters the highest frequency, the hardware sends an interrupt and update > the new highest frequency at which the system can operate. This interrupt > can be enabled via the MSR_HWP_INTERRUPT register, and only if support is > indicated by the CPUID[6].EAX[15] = 1. > > To enable changes to the highest frequency, add a CPU features flag and > enable the HWP (Hardware P-states) highest performance change interrupt > when it is supported by the CPU. > > v2: > - Prevent display in /proc/cpuinfo flags > - Use cpu_feature_enabled() instead of boot_cpu_has() > > Srinivas Pandruvada (2): > x86/cpufeatures: Add HWP highest perf change feature flag > cpufreq: intel_pstate: Support highest performance change interrupt > > arch/x86/include/asm/cpufeatures.h | 1 + > drivers/cpufreq/intel_pstate.c | 23 +++++++++++++++++++---- > 2 files changed, 20 insertions(+), 4 deletions(-) > > -- Please let me know if there are objections against this from the x86 angle. If not, I'll pick it up. Thanks!
On Tue, Jun 25, 2024 at 9:04 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Mon, Jun 24, 2024 at 6:11 PM Srinivas Pandruvada > <srinivas.pandruvada@linux.intel.com> wrote: > > > > Intel Xeon servers, which are capable of dynamic highest performance > > change, are unable to achieve the highest frequency when the performance > > profile is changed. > > > > The highest frequency at which a CPU can operate is not fixed and can > > vary after the system boots. These changes can be initiated by switching > > to different performance profiles using the Intel Speed Select Technology > > interface. Additionally, adjustments can be made remotely through a BMC > > (Baseboard Management Controller) interface. Administrators can select > > various performance profiles to align with specific performance > > requirements, as these choices will directly influence the total power > > consumption and cooling requirements. > > > > Whenever an administrator switches to a different performance profile that > > alters the highest frequency, the hardware sends an interrupt and update > > the new highest frequency at which the system can operate. This interrupt > > can be enabled via the MSR_HWP_INTERRUPT register, and only if support is > > indicated by the CPUID[6].EAX[15] = 1. > > > > To enable changes to the highest frequency, add a CPU features flag and > > enable the HWP (Hardware P-states) highest performance change interrupt > > when it is supported by the CPU. > > > > v2: > > - Prevent display in /proc/cpuinfo flags > > - Use cpu_feature_enabled() instead of boot_cpu_has() > > > > Srinivas Pandruvada (2): > > x86/cpufeatures: Add HWP highest perf change feature flag > > cpufreq: intel_pstate: Support highest performance change interrupt > > > > arch/x86/include/asm/cpufeatures.h | 1 + > > drivers/cpufreq/intel_pstate.c | 23 +++++++++++++++++++---- > > 2 files changed, 20 insertions(+), 4 deletions(-) > > > > -- > > Please let me know if there are objections against this from the x86 angle. > > If not, I'll pick it up. Applied now, as 6.11 material. Thanks!