From: Christian Loehle <christian.loehle@arm.com>
To: Sumit Gupta <sumitg@nvidia.com>,
rafael@kernel.org, viresh.kumar@linaro.org, lenb@kernel.org,
pierre.gondois@arm.com, zhenglifeng1@huawei.com,
zhanjie9@hisilicon.com, mario.limonciello@amd.com,
saket.dumbre@intel.com, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
acpica-devel@lists.linux.dev
Cc: treding@nvidia.com, jonathanh@nvidia.com, vsethi@nvidia.com,
ksitaraman@nvidia.com, sanjayc@nvidia.com, mochs@nvidia.com,
bbasu@nvidia.com
Subject: Re: [PATCH v4 2/2] ACPI: CPPC: Add ospm_nominal_perf support
Date: Fri, 29 May 2026 14:12:02 +0100 [thread overview]
Message-ID: <19b92583-ab78-4b45-a260-03a13874b0fe@arm.com> (raw)
In-Reply-To: <20260527194626.185286-3-sumitg@nvidia.com>
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@nvidia.com>
> ---
> .../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@vger.kernel.org
> +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.]"
next prev parent reply other threads:[~2026-05-29 13:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-27 19:46 [PATCH v4 0/2] ACPI: CPPC: Add CPPC v4 support (ACPI 6.6) Sumit Gupta
2026-05-27 19:46 ` [PATCH v4 1/2] ACPI: CPPC: Add support for CPPC v4 Sumit Gupta
2026-06-01 17:35 ` Rafael J. Wysocki
2026-06-01 18:01 ` Sumit Gupta
2026-06-01 18:11 ` Rafael J. Wysocki
2026-05-27 19:46 ` [PATCH v4 2/2] ACPI: CPPC: Add ospm_nominal_perf support Sumit Gupta
2026-05-28 12:12 ` Pierre Gondois
2026-06-09 7:47 ` Sumit Gupta
2026-05-29 13:12 ` Christian Loehle [this message]
2026-06-09 7:37 ` Sumit Gupta
2026-06-01 17:37 ` Rafael J. Wysocki
2026-06-09 9:59 ` Sumit Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19b92583-ab78-4b45-a260-03a13874b0fe@arm.com \
--to=christian.loehle@arm.com \
--cc=acpica-devel@lists.linux.dev \
--cc=bbasu@nvidia.com \
--cc=jonathanh@nvidia.com \
--cc=ksitaraman@nvidia.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mochs@nvidia.com \
--cc=pierre.gondois@arm.com \
--cc=rafael@kernel.org \
--cc=saket.dumbre@intel.com \
--cc=sanjayc@nvidia.com \
--cc=sumitg@nvidia.com \
--cc=treding@nvidia.com \
--cc=viresh.kumar@linaro.org \
--cc=vsethi@nvidia.com \
--cc=zhanjie9@hisilicon.com \
--cc=zhenglifeng1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®