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@xxxxxxxxxx>
>
> 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@xxxxxxxxxx/
> >
> >   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)