Re: [PATCH v4 2/2] ACPI: CPPC: Add ospm_nominal_perf support

[Sumit Gupta]

On 29/05/26 18:42, Christian Loehle wrote:
> External email: Use caution opening links or attachments
>
>
> On 5/27/26 20:46, Sumit Gupta wrote:
> > Expose the OSPM Nominal Performance register (ACPI 6.6, Section
> > 8.4.6.1.2.6), which conveys the desired nominal performance level
> > at which the platform may run. Unlike the existing read-only
> > Nominal Performance register, it is writable and lets OSPM
> > request a lower nominal level than the platform-reported nominal.
> > The platform classifies performance above this level as boosted
> > and below as throttled for its power/thermal decisions.
> >
> > It is exposed as a per-policy cpufreq sysfs attribute in kHz, to
> > match the cpufreq sysfs unit convention:
> >
> >    /sys/devices/system/cpu/cpufreq/policyN/ospm_nominal_freq
> >
> > The attribute is documented in
> > Documentation/ABI/testing/sysfs-devices-system-cpu.
> >
> > Writes are converted to perf via cppc_khz_to_perf(), validated
> > against [Lowest Performance, Nominal Performance], and applied to
> > every CPU in policy->cpus.
> >
> > The register is write-only; the kernel caches the last written
> > value in struct cppc_cpudata for sysfs readback (returns 0 until
> > userspace writes a value).
> >
> > Signed-off-by: Sumit Gupta <sumitg@xxxxxxxxxx>
> > ---
> >   .../ABI/testing/sysfs-devices-system-cpu      | 17 ++++++
> >   drivers/acpi/cppc_acpi.c                      | 35 +++++++++++
> >   drivers/cpufreq/cppc_cpufreq.c                | 60 +++++++++++++++++++
> >   include/acpi/cppc_acpi.h                      | 12 ++++
> >   4 files changed, 124 insertions(+)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
> > index 82d10d556cc8..ac1bf1b89ac4 100644
> > --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> > +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> > @@ -346,6 +346,23 @@ Description:     Performance Limited
> >
> >                This file is only present if the cppc-cpufreq driver is in use.
> >
> > +What:                /sys/devices/system/cpu/cpuX/cpufreq/ospm_nominal_freq
> > +Date:                May 2026
> > +Contact:     linux-pm@xxxxxxxxxxxxxxx
> > +Description: OSPM Nominal Performance (kHz)
> > +
> > +             OSPM uses this attribute to request a nominal performance
> > +             level lower than the platform-reported nominal. The
> > +             platform treats performance above this level as boost
> > +             and below as throttle for power and thermal decisions.
> > +
> > +             Read returns the last written value in kHz, or 0 if no
> > +             value has been written. Write a kHz value in the range
> > +             [lowest_freq, nominal_freq].
> > +
> > +             This file is only present if the cppc-cpufreq driver is
> > +             in use.
> > +
> Given that this value, based also on firmware behavior, can create vast asymmetries
> between CPUs, which the scheduler would be unaware of I wonder if this warrants
> a similar disclaimer like intel_pstate carries for their per-CPU EPP:
> https://www.kernel.org/doc/html/v7.0/admin-guide/pm/intel_pstate.html#energy-vs-performance-hints
>
> "[Note that tasks may by migrated from one CPU to another by the scheduler’s load-balancing algorithm and if different energy vs performance hints are set for those CPUs, that may lead to undesirable outcomes. To avoid such issues it is better to set the same energy vs performance hint for all CPUs or to pin every task potentially sensitive to them to a specific CPU.]"

Good point.
In v5 added below to the sysfs ABI doc, modeled on similar note:

  Note that tasks may be migrated from one CPU to another
  by the scheduler's load-balancing algorithm, and if
  different OSPM Nominal Performance values are set for
  those CPUs, that may lead to undesirable outcomes. To
  avoid such issues it is better to set the same value
  across all policies, or to pin every potentially
  sensitive task to a specific CPU.

Thank you,
Sumit Gupta