mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
To: Jim Mattson <jmattson@google.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	bp@alien8.de, tglx@kernel.org, x86@kernel.org,
	viresh.kumar@linaro.org, yosry@kernel.org,
	andrew.cooper3@citrix.com, ludloff@gmail.com,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Sashiko <sashiko-bot@kernel.org>,
	zhongqiu.han@oss.qualcomm.com
Subject: Re: [PATCH v3 3/4] cpufreq: ACPI: Use IPI to update boost MSR in cpufreq_boost_down_prep()
Date: Fri, 17 Jul 2026 23:25:13 +0800	[thread overview]
Message-ID: <36d66d21-a1f1-4acb-8ed0-9dbc5c924abd@oss.qualcomm.com> (raw)
In-Reply-To: <CALMp9eR1_ud8-qi+iHHRmCYtrwU2vKE5PkQDPDS=7Rja5eKnQw@mail.gmail.com>

On 7/17/2026 3:11 AM, Jim Mattson wrote:
> On Thu, Jun 25, 2026 at 8:50 AM Zhongqiu Han
> <zhongqiu.han@oss.qualcomm.com> wrote:
> 
>> Hi Rafael,
>> Thanks for the clarification.
>>
>> I agree. Just for discussion, two possible approaches come to mind:
>>
>> Option 1 (structurally clean):
>> Introduce an optional per-CPU cpufreq_driver->set_boost_cpu(cpu, enable)
>> hook and call it from __cpufreq_offline() before cpumask_clear_cpu(),
>> but only on the unbind path (not on plain CPU hotplug-offline - clearing
>> it there maybe wrongly re-enable boost on a still-online sibling on
>> shared-scope HW). Roughly (rough sketch only):
>>
>> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
>> index 21639d9ac753..5f298fbb0d8c 100644
>> --- a/drivers/cpufreq/acpi-cpufreq.c
>> +++ b/drivers/cpufreq/acpi-cpufreq.c
>> @@ -525,13 +525,10 @@ static void free_acpi_perf_data(void)
>>           free_percpu(acpi_perf_data);
>>    }
>>
>> -static int cpufreq_boost_down_prep(unsigned int cpu)
>> +static void acpi_cpufreq_set_boost_cpu(unsigned int cpu, bool enable)
>>    {
>> -       /*
>> -        * Clear the boost-disable bit on the CPU_DOWN path so that
>> -        * this cpu cannot block the remaining ones from boosting.
>> -        */
>> -       return boost_set_msr(1);
>> +       smp_call_function_single(cpu, boost_set_msr_each,
>> +                                (void *)(long)enable, 1);
>>    }
>>
>>    /*
>> @@ -951,7 +948,6 @@ static void acpi_cpufreq_cpu_exit(struct
>> cpufreq_policy *policy)
>>
>>           pr_debug("%s\n", __func__);
>>
>> -       cpufreq_boost_down_prep(policy->cpu);
>>           policy->fast_switch_possible = false;
>>           policy->driver_data = NULL;
>>           acpi_processor_unregister_performance(data->acpi_perf_cpu);
>> @@ -986,6 +982,7 @@ static struct cpufreq_driver acpi_cpufreq_driver = {
>>           .bios_limit     = acpi_processor_get_bios_limit,
>>           .init           = acpi_cpufreq_cpu_init,
>>           .exit           = acpi_cpufreq_cpu_exit,
>> +       .set_boost_cpu  = acpi_cpufreq_set_boost_cpu,
>>           .resume         = acpi_cpufreq_resume,
>>           .name           = "acpi-cpufreq",
>>           .attr           = acpi_cpufreq_attr,
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 507224c9ecd3..c4952ca3e8a5 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -1669,13 +1669,18 @@ static int cpufreq_add_dev(struct device *dev,
>> struct subsys_interface *sif)
>>           return 0;
>>    }
>>
>> -static void __cpufreq_offline(unsigned int cpu, struct cpufreq_policy
>> *policy)
>> +static void __cpufreq_offline(unsigned int cpu, struct cpufreq_policy
>> *policy,
>> +                             bool unbinding)
>>    {
>>           int ret;
>>
>>           if (has_target())
>>                   cpufreq_stop_governor(policy);
>>
>> +       if (unbinding && cpufreq_driver->set_boost_cpu &&
>> +           policy->boost_supported)
>> +               cpufreq_driver->set_boost_cpu(cpu, true);
>> +
>>           cpumask_clear_cpu(cpu, policy->cpus);
>>
>>           if (!policy_is_inactive(policy)) {
>> @@ -1730,7 +1735,7 @@ static int cpufreq_offline(unsigned int cpu)
>>
>>           guard(cpufreq_policy_write)(policy);
>>
>> -       __cpufreq_offline(cpu, policy);
>> +       __cpufreq_offline(cpu, policy, false);
>>
>>           return 0;
>>    }
>> @@ -1750,7 +1755,7 @@ static void cpufreq_remove_dev(struct device *dev,
>> struct subsys_interface *sif)
>>
>>           scoped_guard(cpufreq_policy_write, policy) {
>>                   if (cpu_online(cpu))
>> -                       __cpufreq_offline(cpu, policy);
>> +                       __cpufreq_offline(cpu, policy, true);
>>
>>                   remove_cpu_dev_symlink(policy, cpu, dev);
>>
>> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
>> index ae9d1ce4f49c..c174b013dd76 100644
>> --- a/include/linux/cpufreq.h
>> +++ b/include/linux/cpufreq.h
>> @@ -413,6 +413,8 @@ struct cpufreq_driver {
>>           int             (*online)(struct cpufreq_policy *policy);
>>           int             (*offline)(struct cpufreq_policy *policy);
>>           void            (*exit)(struct cpufreq_policy *policy);
>> +       /* Optional */
>> +       void            (*set_boost_cpu)(unsigned int cpu, bool enable);
>>           int             (*suspend)(struct cpufreq_policy *policy);
>>           int             (*resume)(struct cpufreq_policy *policy);
>>
>>
>>
>> Option 2 (lighter, but it is at odds with the direction discussed
>> above): stay in acpi-cpufreq's ->exit() and restore over
>> policy->related_cpus instead.
>>
>>
>>
>>
>> --
>> Thx and BRs,
>> Zhongqiu Han
> 
> While you negotiate the cleanup, should I remove this change from the series?

Thanks a lot Jim for the checking. Maybe Rafael or Viresh can help
comment on this.


Besides, one possible improvement over Option 1 is to leave the
`cpufreq_offline()` API unchanged, and instead move the set boost-bit
callback into `cpufreq_remove_dev()`. To avoid redundant IPIs, place it
after

     if (!cpumask_empty(policy->real_cpus))
         return;

and use `related_cpus` instead of `policy->cpus` (because `policy->cpus`
is emptied after `__cpufreq_offline()` is called).

Pseudo-code:

     scoped_guard(cpufreq_policy_write, policy) {
         if (cpu_online(cpu))
             __cpufreq_offline(cpu, policy);

             remove_cpu_dev_symlink(policy, cpu, dev);

             if (!cpumask_empty(policy->real_cpus))
                 return;

+           if (cpufreq_driver->set_boost_cpu
                 && policy->boost_supported)
+               cpufreq_driver->set_boost_cpu(policy->related_cpus);
+
         /*
          * Unregister cpufreq cooling once all the CPUs of the policy
          * are removed.
          */


-- 
Thx and BRs,
Zhongqiu Han

  reply	other threads:[~2026-07-17 15:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-18 22:45 [PATCH v3 0/4] Fix racy and incorrect updates to MSR_K7_HWCR Jim Mattson
2026-06-18 22:45 ` [PATCH v3 1/4] x86/CPU/AMD: Avoid racy updates to MSR_K7_HWCR in set_cpuid_faulting() Jim Mattson
2026-06-18 22:45 ` [PATCH v3 2/4] x86/mce/inject: Avoid racy updates to MSR_K7_HWCR during MCE injection Jim Mattson
2026-06-18 22:45 ` [PATCH v3 3/4] cpufreq: ACPI: Use IPI to update boost MSR in cpufreq_boost_down_prep() Jim Mattson
2026-06-23 12:47   ` Rafael J. Wysocki
2026-06-24 11:25     ` Zhongqiu Han
2026-06-24 13:35       ` Rafael J. Wysocki
2026-06-25 15:50         ` Zhongqiu Han
2026-07-16 19:11           ` Jim Mattson
2026-07-17 15:25             ` Zhongqiu Han [this message]
2026-06-18 22:45 ` [PATCH v3 4/4] cpufreq: ACPI: Use amd_update_hwcr() for MSR_K7_HWCR updates Jim Mattson
2026-06-23 12:15   ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=36d66d21-a1f1-4acb-8ed0-9dbc5c924abd@oss.qualcomm.com \
    --to=zhongqiu.han@oss.qualcomm.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=jmattson@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=ludloff@gmail.com \
    --cc=rafael@kernel.org \
    --cc=sashiko-bot@kernel.org \
    --cc=tglx@kernel.org \
    --cc=viresh.kumar@linaro.org \
    --cc=x86@kernel.org \
    --cc=yosry@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®