Re: [PATCH v2] cpufreq: CPPC: Enable boost by default when supported

[Christian Loehle <christian.loehle@arm.com>]

On 11/4/26 07:43, Pengjie Zhang wrote:
> 
> On 10/29/2026 4:51 AM, Christian Loehle wrote:
>> On 10/22/26 08:59, Pengjie Zhang wrote:
>>> The CPPC driver leaves boost disabled by default when Highest Performance
>>> exceeds Nominal Performance. Userspace must explicitly enable boost
>>> before governors can use the full advertised performance range.
>>>
>>> Enable boost by default when at least one possible CPU reports support,
>>> while users who prefer to stay within the sustained nominal limit can
>>> still disable it via the boost knob without determining scaling_max_freq
>>> for each policy.
>>>
>>> Check the performance capabilities before registering the driver so that
>>> the cpufreq core enables boost for each policy that supports it.
>>>
>>> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
>>
>> Just to be clear I'm not blocking this per se, but continuing my comments:
>>
>> I just wonder if this is a configuration worth keeping.
>> You mentioned your platforms have a BIOS to set nominal==highest or not.
>> If we removed interpreting highest - nominal as boost entirely that
>> would also make that BIOS setting obsolete. Userspace could still
>> query nominal and restrict cpufreq to that if it wishes to do that,
>> we could add that to cpupower for convenience (i.e. set all policies'
>> max to nominal).
>>
>> With the changes that are coming with CPCv4 we would save ourselves
>> some headache (like keeping track of boost status when ospm_nominal_perf
>> is being written).
>>
>> The question is also how often the combination of "enable nominal < highest"
>> and then explicitly toggling boost at runtime actually happens...
>>
>>> ---
>>> Changes in v2:
>>> - Drop "even" and clarify the commit message (Christian).
>>> - Link to v1: https://lore.kernel.org/all/20261015015812.867988-1-zhangpengjie2@huawei.com/
>>>
>>>   drivers/cpufreq/cppc_cpufreq.c | 20 ++++++++++++++++++++
>>>   1 file changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
>>> index 80893844353c..0a4255a36f60 100644
>>> --- a/drivers/cpufreq/cppc_cpufreq.c
>>> +++ b/drivers/cpufreq/cppc_cpufreq.c
>>> @@ -1052,6 +1052,25 @@ static struct cpufreq_driver cppc_cpufreq_driver = {
>>>       .name = "cppc_cpufreq",
>>>   };
>>>   +static void __init cppc_cpufreq_default_boost_init(void)
>>> +{
>>> +    struct cppc_perf_caps caps;
>>> +    bool enable = false;
>>> +    int cpu;
>>> +
>>> +    for_each_possible_cpu(cpu) {
>>> +        if (cppc_get_perf_caps(cpu, &caps))
>>> +            continue;
>>> +
>>> +        if (caps.highest_perf > caps.nominal_perf) {
>>> +            enable = true;
>>> +            break;
>>> +        }
>>> +    }
>>> +
>>> +    cppc_cpufreq_driver.boost_enabled = enable;
>> Any reason for the scan instead of just setting
>> boost_enabled = true? Platforms without boost would
>> also expose the toggle, but that's mostly in line with
>> the other drivers? (also again the ospm_nominal_perf
>> angle)
> 
> The reason for scanning here is to keep the initial sysfs state
> consistent on platforms where highest_perf == nominal_perf on all CPUs
> (i.e. policy->boost_supported is false everywhere). If we just set
> boost_enabled = true unconditionally, the global cpufreq/boost file will
> read 1 on boot while every policyX/boost reads 0 (and rejects writes
> with -EINVAL).

FWIW, amd-pstate can already expose global boost=1 while all per-policy
boost knobs read 0 and writes to either knob then fail with -EINVAL AFAICS?

AFAIU the global sysfs knob represents permission to boost where
supported, rather than meaning boost is supported, too?

PS:
Also another fun one I discovered...
power-orion-o6-01# cat /sys/devices/system/cpu/cpufreq/boost 
0
power-orion-o6-01# echo 1 > /sys/devices/system/cpu/cpufreq/boost
echo: write error: invalid argument
power-orion-o6-01# cat /sys/devices/system/cpu/cpufreq/boost 
0
power-orion-o6-01# echo 0 > /sys/devices/system/cpu/cpufreq/boost
echo: write error: invalid argument
power-orion-o6-01# cat /sys/devices/system/cpu/cpufreq/boost     
1

I'll go and fix that...

> 
> Also, since ospm_nominal_perf has a valid range of [lowest_perf,
> nominal_perf], it actually pairs quite well with the boost knob: on
> platforms with highest_perf > nominal_perf, ospm_nominal_perf will
> always stay below highest_perf, and even on platforms with
> nominal_perf == highest_perf, lowering ospm_nominal_perf could
> dynamically define a nominal ceiling for when boost is disabled.

I don't think I agree with the latter. OSPM nominal has its own (platform)
semantics, but making boost=0 impose that value as a frequency ceiling
is just another way of setting scaling_max_freq.
I don't see why these two need to be coupled?

Also I think the fact that caps.highest_perf == caps.nominal_perf
but ospm_nominal_perf can change boost supported later is a reason
against the boot-time scan? (which would need to exclude
ospm_nominal_perf platforms?)