Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230115235202.24695-1-bhuwz@163.com>
In-Reply-To: <20230115235202.24695-1-bhuwz@163.com>
From:   "Rafael J. Wysocki" <rafael@kernel.org>
Date:   Tue, 17 Jan 2023 14:30:17 +0100
Message-ID: <CAJZ5v0iobEEpOY-ww6GqBbKk-MKmyWFSLi8akVUM9fZT7foSUw@mail.gmail.com>
Subject: Re: [PATCH] cpufreq: Send CPUFREQ_CREATE_POLICY notification after
 the perf domain creation.
To:     Vincent Wang <bhuwz@163.com>
Cc:     rafael@kernel.org, viresh.kumar@linaro.org,
        linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
        Vincent Wang <vincentwang3@lenovo.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jan 16, 2023 at 12:52 AM Vincent Wang <bhuwz@163.com> wrote:
>
> From: Vincent Wang <vincentwang3@lenovo.com>
>
> We found the following issue during kernel boot on android phone:
>
> [    1.325272][    T1] cpu cpu0: EM: created perf domain
> [    1.329317][    T1] cpu cpu4: EM: created perf domain
> [    1.337597][   T76] pd_init: no EM found for CPU7
> [    1.350849][    T1] cpu cpu7: EM: created perf domain
>
> pd init for cluster2 is executed in a kworker thread and
> is earlier than the perf domain creation for cluster2.
>
> pd_init() is called from the cpufreq notification of
> CPUFREQ_CREATE_POLICY in cpufreq_online(), which is earlier
> than that cpufreq_driver->register_em() is called.
>
> To avoid this issue, cpufreq notification should be sent after
> the perf domain creation.
>
> Signed-off-by: Vincent Wang <vincentwang3@lenovo.com>
> ---
>  drivers/cpufreq/cpufreq.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 7e56a42750ea..af8836069398 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1430,9 +1430,6 @@ static int cpufreq_online(unsigned int cpu)
>                         policy->max_freq_req = NULL;
>                         goto out_destroy_policy;
>                 }
> -
> -               blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> -                               CPUFREQ_CREATE_POLICY, policy);
>         }

AFAICS, in some cases, this may cause cpufreq_online() to send
CPUFREQ_REMOVE_POLICY without sending CPUFREQ_CREATE_POLICY which is
generally confusing to its callers.

I'm wondering if you can reorder the EM registration before the
initialization of frequency QoS for the policy?

>
>         if (cpufreq_driver->get && has_target()) {
> @@ -1506,6 +1503,9 @@ static int cpufreq_online(unsigned int cpu)
>                  */
>                 if (cpufreq_driver->register_em)
>                         cpufreq_driver->register_em(policy);
> +
> +               blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> +                               CPUFREQ_CREATE_POLICY, policy);
>         }
>
>         ret = cpufreq_init_policy(policy);
> --