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

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

[Pengjie Zhang]

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>
---
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;
+}
+
 static int __init cppc_cpufreq_init(void)
 {
 	int ret;
@@ -1061,6 +1080,7 @@ static int __init cppc_cpufreq_init(void)
 
 	cppc_freq_invariance_init();
 	populate_efficiency_class();
+	cppc_cpufreq_default_boost_init();
 
 	ret = cpufreq_register_driver(&cppc_cpufreq_driver);
 	if (ret)
-- 
2.33.0

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

[Pengjie Zhang]

+cc Christian Loehle

On 10/22/2026 3:59 PM, 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>
> ---
> 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;
> +}
> +
>   static int __init cppc_cpufreq_init(void)
>   {
>   	int ret;
> @@ -1061,6 +1080,7 @@ static int __init cppc_cpufreq_init(void)
>   
>   	cppc_freq_invariance_init();
>   	populate_efficiency_class();
> +	cppc_cpufreq_default_boost_init();
>   
>   	ret = cpufreq_register_driver(&cppc_cpufreq_driver);
>   	if (ret)

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

[Christian Loehle]

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)

> +}
> +
>  static int __init cppc_cpufreq_init(void)
>  {
>  	int ret;
> @@ -1061,6 +1080,7 @@ static int __init cppc_cpufreq_init(void)
>  
>  	cppc_freq_invariance_init();
>  	populate_efficiency_class();
> +	cppc_cpufreq_default_boost_init();
>  
>  	ret = cpufreq_register_driver(&cppc_cpufreq_driver);
>  	if (ret)

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

[Jie Zhan]

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).
That would be just some bonus functions.

I think the idea is to give userspace a knob to toggle boost on/off and
check the current status.

As of now, we don't have a better way to achieve this other than taking
highest > nominal.
> 
> The question is also how often the combination of "enable nominal < highest"
> and then explicitly toggling boost at runtime actually happens...
> 
In most cases, it's only set up once on boot.
Some experimental, debugging, or clever userspace strategies may toggle it
more often. Who knows :)

[...]

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

[Pengjie Zhang]

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).

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.

Thanks,
Pengjie

>> +}
>> +
>>   static int __init cppc_cpufreq_init(void)
>>   {
>>   	int ret;
>> @@ -1061,6 +1080,7 @@ static int __init cppc_cpufreq_init(void)
>>   
>>   	cppc_freq_invariance_init();
>>   	populate_efficiency_class();
>> +	cppc_cpufreq_default_boost_init();
>>   
>>   	ret = cpufreq_register_driver(&cppc_cpufreq_driver);
>>   	if (ret)
>

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

[Christian Loehle]

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?)

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

[Pengjie Zhang]

On 11/5/2026 12:12 AM, Christian Loehle wrote:
> 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?

Yes, Documentation/admin-guide/pm/cpufreq.rst also states that 1 in the
global boost file "only means a permission to use the frequency boost
mechanism (which still may never be used for other reasons)", while 0
means it "is disabled and cannot be used at all".

> 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?)

Fair enough, ospm_nominal_perf doesn't need to be coupled with boost.

Viresh, Rafael, any preference here? Should we keep the boot-time check
in v2 (so global boost stays 0 on platforms without boost support), or
drop the scan and just set .boost_enabled = true statically in
cppc_cpufreq_driver?

Thanks,
Pengjie

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

[Rafael J. Wysocki (Intel)]

On Thu, Nov 5, 2026 at 8:04 AM Pengjie Zhang <zhangpengjie2@huawei.com> wrote:
>
>
> On 11/5/2026 12:12 AM, Christian Loehle wrote:
> > 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?
>
> Yes, Documentation/admin-guide/pm/cpufreq.rst also states that 1 in the
> global boost file "only means a permission to use the frequency boost
> mechanism (which still may never be used for other reasons)", while 0
> means it "is disabled and cannot be used at all".
>
> > 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?)
>
> Fair enough, ospm_nominal_perf doesn't need to be coupled with boost.
>
> Viresh, Rafael, any preference here? Should we keep the boot-time check
> in v2 (so global boost stays 0 on platforms without boost support), or
> drop the scan and just set .boost_enabled = true statically in
> cppc_cpufreq_driver?

I have no specific opinions regarding boost support other than it's
better be made consistent across all drivers and the core.