Re: [PATCH v2 0/2] Update highest frequency of a CPU after boot

[Rafael J. Wysocki]

On Tue, Jun 25, 2024 at 9:04 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>
> On Mon, Jun 24, 2024 at 6:11 PM Srinivas Pandruvada
> <srinivas.pandruvada@xxxxxxxxxxxxxxx> 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!