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