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

[Pengjie Zhang <zhangpengjie2@huawei.com>]

Hi Christian,

Thanks for the review.

On 10/15/2026 4:42 PM, Christian Loehle wrote:
> On 10/15/26 02:58, Pengjie Zhang wrote:
>> The CPPC driver leaves boost disabled by default, even when Highest
> "even"? That's the only case where disabling it even means something?

Agreed, I'll remove "even" in v2.

>> Performance exceeds Nominal Performance. Userspace must explicitly
>> enable boost before governors can use the full advertised performance
>> range.
>>
>> For user convenience, enable boost by default when at least one possible
>> CPU reports support. 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>
> I often wonder if we should keep boost altogether, the power and
> thermal envelope on silicon nowadays is complex enough for this to have
> little meaning, it in no way guarantees no throttling or that you receive
> the requested performance.
I agree that enabling boost does not guarantee the requested performance.

However, CPPC distinguishes Nominal from Highest Performance. Highest
Performance may not be sustainable for long durations, while Nominal
Performance is expected to be able to maintain continuously.

Boost control lets user trade off burst capacity above nominal against
staying within safe limits. While performance won't be completely steady,
having that flexibility is worth it."

> The (silicon-aware) user can always individually set the ceilings s.t.
> it 'works' for their platform/workload/environment combination via
> scaling_max_freq.
Yes, but users need to determine an appropriate frequency ceiling for
their platform. The boost  provides a simpler way to select the
nominal limit without determining its frequency value for each policy.
>
> Since commit 54e74df5d76d
> was also introduced by Huawei I'd be curious about the usage there,
> AFAICS having a platform with NOMINAL_PERF != HIGHEST_PERF is just
> additional headache on linux for now?
On our server platforms, users can configure whether firmware advertises
highest_perf above nominal_perf. CPPC defines both performance levels and
allows them to differ.

My proposal makes that advertised range available by default while
retaining the boost control for users who want to exclude it.

Thanks,
Pengjie


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