The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Mario Limonciello <mario.limonciello@amd.com>
To: Sumit Gupta <sumitg@nvidia.com>,
	rafael@kernel.org, viresh.kumar@linaro.org,
	pierre.gondois@arm.com, ionela.voinescu@arm.com,
	zhenglifeng1@huawei.com, zhanjie9@hisilicon.com, corbet@lwn.net,
	skhan@linuxfoundation.org, rdunlap@infradead.org,
	linux-pm@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: linux-tegra@vger.kernel.org, treding@nvidia.com,
	jonathanh@nvidia.com, vsethi@nvidia.com, ksitaraman@nvidia.com,
	sanjayc@nvidia.com, mochs@nvidia.com, bbasu@nvidia.com
Subject: Re: [PATCH v3 2/2] cpufreq: CPPC: add autonomous mode boot parameter support
Date: Mon, 18 May 2026 13:08:06 -0500	[thread overview]
Message-ID: <ad24ad9a-2b30-4952-b36a-210c08a62346@amd.com> (raw)
In-Reply-To: <985f976f-1144-445b-96c2-df5bd57ecf05@nvidia.com>



On 5/18/26 12:22, Sumit Gupta wrote:
> 
> On 18/05/26 19:51, Mario Limonciello wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On 5/18/26 09:15, Sumit Gupta wrote:
>>>
>>> On 18/05/26 19:20, Mario Limonciello wrote:
>>>> External email: Use caution opening links or attachments
>>>>
>>>>
>>>> On 5/18/26 08:44, Sumit Gupta wrote:
>>>>> Hi Mario,
>>>>>
>>>>>
>>>>> On 16/05/26 02:43, Mario Limonciello wrote:
>>>>>> External email: Use caution opening links or attachments
>>>>>>
>>>>>>
>>>>>> On 5/15/26 07:26, Sumit Gupta wrote:
>>>>>>> Add a kernel boot parameter 'cppc_cpufreq.auto_sel_mode' to enable
>>>>>>> CPPC autonomous performance selection on all CPUs at system startup.
>>>>>>> When autonomous mode is enabled, the hardware automatically adjusts
>>>>>>> CPU performance based on workload demands using Energy Performance
>>>>>>> Preference (EPP) hints.
>>>>>>>
>>>>>>> When the parameter is set:
>>>>>>> - Configure all CPUs for autonomous operation on first init
>>>>>>> - Use HW min/max_perf when available; otherwise initialize from caps
>>>>>>> - Initialize desired_perf to max_perf as a starting hint
>>>>>>> - Hardware controls frequency instead of the OS governor
>>>>>>> - EPP behavior depends on parameter value:
>>>>>>>    - performance (or 1): override EPP to performance preference 
>>>>>>> (0x0)
>>>>>>>    - default_epp (or 2): preserve EPP value programmed by BIOS/
>>>>>>> firmware
>>>>>>>
>>>>>>> The boot parameter is applied only during first policy 
>>>>>>> initialization.
>>>>>>> Skip applying it on CPU hotplug to preserve runtime sysfs
>>>>>>> configuration.
>>>>>>>
>>>>>>> This patch depends on patch series [1] ("cpufreq: Set policy->min 
>>>>>>> and
>>>>>>> max as real QoS constraints") so that the policy->min/max set in
>>>>>>> cppc_cpufreq_cpu_init() are not overridden by cpufreq_set_policy()
>>>>>>> during init.
>>>>>>>
>>>>>>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
>>>>>>> ---
>>>>>>> [1] https://lore.kernel.org/lkml/20260511135538.522653-1-
>>>>>>> pierre.gondois@arm.com/
>>>>>>> ---
>>>>>>>   .../admin-guide/kernel-parameters.txt         |  16 +++
>>>>>>>   drivers/cpufreq/cppc_cpufreq.c                | 122 +++++++++++++
>>>>>>> ++++-
>>>>>>>   2 files changed, 133 insertions(+), 5 deletions(-)
>>>>>>>
>>>>>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/
>>>>>>> Documentation/admin-guide/kernel-parameters.txt
>>>>>>> index 0eb64aab3685..7e4b3a8fd76f 100644
>>>>>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>>>>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>>>>>> @@ -1048,6 +1048,22 @@ Kernel parameters
>>>>>>>                       policy to use. This governor must be 
>>>>>>> registered
>>>>>>> in the
>>>>>>>                       kernel before the cpufreq driver probes.
>>>>>>>
>>>>>>> +     cppc_cpufreq.auto_sel_mode=
>>>>>>> +                     [CPU_FREQ] Enable ACPI CPPC autonomous
>>>>>>> performance
>>>>>>> +                     selection. When enabled, hardware 
>>>>>>> automatically
>>>>>>> adjusts
>>>>>>> +                     CPU frequency on all CPUs based on workload
>>>>>>> demands.
>>>>>>> +                     In Autonomous mode, Energy Performance
>>>>>>> Preference (EPP)
>>>>>>> +                     hints guide hardware toward performance (0x0)
>>>>>>> or energy
>>>>>>> +                     efficiency (0xff).
>>>>>>> +                     Requires ACPI CPPC autonomous selection 
>>>>>>> register
>>>>>>> +                     support.
>>>>>>> +                     Accepts:
>>>>>>> +                       performance, 1: enable auto_sel + set EPP to
>>>>>>> +                                       performance (0x0)
>>>>>>> +                       default_epp, 2: enable auto_sel, preserve 
>>>>>>> EPP
>>>>>>> value
>>>>>>> +                                       programmed by BIOS/firmware
>>>>>>> +                     Unset: cpufreq governors are used (auto_sel
>>>>>>> disabled).
>>>>>>
>>>>>> Rather than unset doing nothing, have you considered having it take a
>>>>>> midpoint like 128?  That's what we do in amd-pstate (default to
>>>>>> balance_performance).  I think it turns into a reasonable balance.
>>>>>
>>>>> Thanks for the suggestion.
>>>>> I can add balance_performance that enables auto_sel with EPP=128 in 
>>>>> v4.
>>>>>
>>>>> On changing the driver default (no param behavior) to auto enable
>>>>> balance_performance, it would be good to keep the current behavior for
>>>>> now since cppc_cpufreq is generic across ARM64/RISC-V platforms where
>>>>> EPP and Autonomous Selection registers are optional.
>>>>> A default change would affect existing users relying on governors.
>>>>>
>>>>> Thank you,
>>>>> Sumit Gupta
>>>>
>>>> But couldn't you make the "no module parameter set" follow the behavior
>>>> to only set the registers if they're available?
>>>>
>>>> So the systems that support it start using it, the ones that don't it's
>>>> a NOP.
>>>>
>>>
>>> Would it work to add balance_performance as a new mode in v4,
>>> and discuss changing the default separately as a follow-up?
>>>
>>
>> Sure.
>>
>>> Runtime detection helps for unsupported platforms. But platforms which
>>> support the registers use OS governors today, and silently switching
>>> them to autonomous mode on a kernel update is a behavior change for
>>> existing users. They would also have no way to boot into sw governor.
>>>
>>
>> But hopefully it should be better battery life/responsiveness for those
>> scenarios too, right?
>>
> 
> Yes in many cases, but if some workloads rely on specific OS governor
> configurations, then that would get impacted.
> I will send a separate change later to seek broader consensus on
> enabling auto_sel as default without any param.
> 

I suppose another option is to have a Kconfig to decide at compile time 
whether to turn on autonomous mode by default, so systems can avoid 
moving to this if they don't want to.


  reply	other threads:[~2026-05-18 18:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-15 12:26 [PATCH v3 0/2] cpufreq: CPPC: add autonomous mode boot parameter support Sumit Gupta
2026-05-15 12:26 ` [PATCH v3 1/2] cpufreq: CPPC: Set CPPC Enable register in cpu_init Sumit Gupta
2026-05-15 12:26 ` [PATCH v3 2/2] cpufreq: CPPC: add autonomous mode boot parameter support Sumit Gupta
2026-05-15 21:13   ` Mario Limonciello
2026-05-18 13:44     ` Sumit Gupta
2026-05-18 13:50       ` Mario Limonciello
2026-05-18 14:15         ` Sumit Gupta
2026-05-18 14:21           ` Mario Limonciello
2026-05-18 17:22             ` Sumit Gupta
2026-05-18 18:08               ` Mario Limonciello [this message]
2026-05-15 22:14   ` Randy Dunlap
2026-05-18 13:49     ` 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=ad24ad9a-2b30-4952-b36a-210c08a62346@amd.com \
    --to=mario.limonciello@amd.com \
    --cc=bbasu@nvidia.com \
    --cc=corbet@lwn.net \
    --cc=ionela.voinescu@arm.com \
    --cc=jonathanh@nvidia.com \
    --cc=ksitaraman@nvidia.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mochs@nvidia.com \
    --cc=pierre.gondois@arm.com \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=sanjayc@nvidia.com \
    --cc=skhan@linuxfoundation.org \
    --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