On Fri, Jul 18, 2025 at 4:03 AM Jiayi Li <lijiayi@xxxxxxxxxx> wrote:
>
> The original initialization sequence was:
>
> cpufreq_policy_online()
> acpi_cpufreq_cpu_init()
> acpi_processor_get_platform_limit()
> freq_qos_update_request(&perflib_req)
> blocking_notifier_call_chain(...)
> acpi_processor_ppc_init()
> freq_qos_add_request(&perflib_req)
>
> This caused a race condition where the QoS request was added after the
> initial platform limit update.
To me, the description above is useless for figuring out what's going on, sorry.
This is not a race, but an ordering issue.
The cpufreq driver calls acpi_processor_register_performance(), which
among other things causes acpi_processor_get_platform_limit() to be
called, from its ->init() callback which is invoked by the cpufreq
core before CPUFREQ_CREATE_POLICY notifiers and the policy frequency
QoS requests are added by acpi_processor_notifier(), so they don't
exist when acpi_processor_register_performance() gets called and they
cannot be updated by the acpi_processor_get_platform_limit().
You want them to be updated as soon as they have been added, which is
kind of reasonable, but it needs to be done only if
acpi_processor_register_performance() has been called by the cpufreq
driver.
> The new sequence explicitly ensures:
>
> cpufreq_policy_online()
> acpi_cpufreq_cpu_init()
> acpi_processor_get_platform_limit()
> freq_qos_update_request(&perflib_req)
> blocking_notifier_call_chain(...)
> acpi_processor_ppc_init()
> freq_qos_add_request(&perflib_req)
> + acpi_processor_get_platform_limit()
> + freq_qos_update_request(&perflib_req)
>
> The critical change adds an immediate platform limit update after the
> QoS request is registered. This guarantees that the initial P-state
> constraint is applied before any subsequent updates, resolving the window
> where constraints could be applied out-of-order.
>
> Fixes: d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier")
> Signed-off-by: Jiayi Li <lijiayi@xxxxxxxxxx>
> ---
> drivers/acpi/processor_perflib.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
> index 64b8d1e19594..3e7fe95c21d1 100644
> --- a/drivers/acpi/processor_perflib.c
> +++ b/drivers/acpi/processor_perflib.c
> @@ -173,6 +173,9 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
> {
> unsigned int cpu;
>
> + if (ignore_ppc == 1)
> + return;
> +
> for_each_cpu(cpu, policy->related_cpus) {
> struct acpi_processor *pr = per_cpu(processors, cpu);
> int ret;
So AFAICS this loop needs to check pr->performance in addition to pr.
> @@ -193,6 +196,11 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
> if (ret < 0)
> pr_err("Failed to add freq constraint for CPU%d (%d)\n",
> cpu, ret);
> +
> + ret = acpi_processor_get_platform_limit(pr);
> + if (ret)
> + pr_err("Failed to update freq constraint for CPU%d (%d)\n",
> + cpu, ret);
> }
> }
>
> --
