[PATCH 0/2] cpufreq: Introduce a more generic way to boost when cpu is going online

[PATCH 0/2] cpufreq: Introduce a more generic way to boost when cpu is going online

[Lifeng Zheng]

Since commit f37a4d6b4a2c ("cpufreq: Fix per-policy boost behavior on
SoCs using cpufreq_boost_set_sw()") and commit 102fa9c4b439 ("cpufreq:
Allow drivers to advertise boost enabled"), per-policy boost flag has
already been set to mirror the cpufreq_driver boost during
initialization. However, the current implementation doesn't work for all
cpufreq drivers and may fail in certain situation. A more generic
implementation is needed.

Lifeng Zheng (2):
  cpufreq: Fix re-boost issue after hotplugging a cpu
  cpufreq: Introduce a more generic way to set default per-policy boost
    flag

 drivers/cpufreq/cpufreq.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

-- 
2.33.0

[PATCH 1/2] cpufreq: Fix re-boost issue after hotplugging a cpu

[Lifeng Zheng]

It turns out that cpuX will stay on the base frequency after performing
these operations:

1. boost all cpus: echo 1 > /sys/devices/system/cpu/cpufreq/boost

2. offline the cpu: echo 0 > /sys/devices/system/cpu/cpuX/online

3. deboost all cpus: echo 0 > /sys/devices/system/cpu/cpufreq/boost

4. online the cpu: echo 1 > /sys/devices/system/cpu/cpuX/online

5. boost all cpus again: echo 1 > /sys/devices/system/cpu/cpufreq/boost

This is because max_freq_req of the policy is not updated during the
online process, and the value of max_freq_req before the last offline is
retained. When the CPU is boosted again, freq_qos_update_request() will
do nothing because the old value is the same as the new one. This causes
the CPU stay on the base frequency. Update max_freq_req (and
min_freq_req of course) in cpufreq_online() will solve this problem.

Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
---
 drivers/cpufreq/cpufreq.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 1a4cae54a01b..03ae879d50b9 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1475,6 +1475,13 @@ static int cpufreq_online(unsigned int cpu)
 
 		blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
 				CPUFREQ_CREATE_POLICY, policy);
+	} else {
+		ret = freq_qos_update_request(policy->min_freq_req, policy->min);
+		if (ret < 0)
+			goto out_destroy_policy;
+		ret = freq_qos_update_request(policy->max_freq_req, policy->max);
+		if (ret < 0)
+			goto out_destroy_policy;
 	}
 
 	if (cpufreq_driver->get && has_target()) {
-- 
2.33.0

Re: [PATCH 1/2] cpufreq: Fix re-boost issue after hotplugging a cpu

[Viresh Kumar]

On 15-01-25, 18:01, Lifeng Zheng wrote:
> It turns out that cpuX will stay on the base frequency after performing
> these operations:
> 
> 1. boost all cpus: echo 1 > /sys/devices/system/cpu/cpufreq/boost
> 
> 2. offline the cpu: echo 0 > /sys/devices/system/cpu/cpuX/online
> 
> 3. deboost all cpus: echo 0 > /sys/devices/system/cpu/cpufreq/boost
> 
> 4. online the cpu: echo 1 > /sys/devices/system/cpu/cpuX/online
> 
> 5. boost all cpus again: echo 1 > /sys/devices/system/cpu/cpufreq/boost
> 
> This is because max_freq_req of the policy is not updated during the
> online process, and the value of max_freq_req before the last offline is
> retained. When the CPU is boosted again, freq_qos_update_request() will
> do nothing because the old value is the same as the new one. This causes
> the CPU stay on the base frequency. Update max_freq_req (and
> min_freq_req of course) in cpufreq_online() will solve this problem.
> 
> Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
> ---
>  drivers/cpufreq/cpufreq.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 1a4cae54a01b..03ae879d50b9 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1475,6 +1475,13 @@ static int cpufreq_online(unsigned int cpu)
>  
>  		blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
>  				CPUFREQ_CREATE_POLICY, policy);
> +	} else {
> +		ret = freq_qos_update_request(policy->min_freq_req, policy->min);

This may not be required, as min-freq-req is never updated.

> +		if (ret < 0)
> +			goto out_destroy_policy;
> +		ret = freq_qos_update_request(policy->max_freq_req, policy->max);
> +		if (ret < 0)
> +			goto out_destroy_policy;
>  	}
>  
>  	if (cpufreq_driver->get && has_target()) {
> -- 
> 2.33.0

-- 
viresh

Re: [PATCH 1/2] cpufreq: Fix re-boost issue after hotplugging a cpu

[Rafael J. Wysocki]

On Wed, Jan 15, 2025 at 12:18 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 15-01-25, 18:01, Lifeng Zheng wrote:
> > It turns out that cpuX will stay on the base frequency after performing
> > these operations:
> >
> > 1. boost all cpus: echo 1 > /sys/devices/system/cpu/cpufreq/boost
> >
> > 2. offline the cpu: echo 0 > /sys/devices/system/cpu/cpuX/online
> >
> > 3. deboost all cpus: echo 0 > /sys/devices/system/cpu/cpufreq/boost
> >
> > 4. online the cpu: echo 1 > /sys/devices/system/cpu/cpuX/online
> >
> > 5. boost all cpus again: echo 1 > /sys/devices/system/cpu/cpufreq/boost
> >
> > This is because max_freq_req of the policy is not updated during the
> > online process, and the value of max_freq_req before the last offline is
> > retained. When the CPU is boosted again, freq_qos_update_request() will
> > do nothing because the old value is the same as the new one. This causes
> > the CPU stay on the base frequency. Update max_freq_req (and
> > min_freq_req of course) in cpufreq_online() will solve this problem.
> >
> > Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
> > ---
> >  drivers/cpufreq/cpufreq.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 1a4cae54a01b..03ae879d50b9 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -1475,6 +1475,13 @@ static int cpufreq_online(unsigned int cpu)
> >
> >               blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> >                               CPUFREQ_CREATE_POLICY, policy);
> > +     } else {
> > +             ret = freq_qos_update_request(policy->min_freq_req, policy->min);
>
> This may not be required, as min-freq-req is never updated.

It gets updated via scaling_min_freq AFAICS.  Doesn't this matter?

> > +             if (ret < 0)
> > +                     goto out_destroy_policy;
> > +             ret = freq_qos_update_request(policy->max_freq_req, policy->max);
> > +             if (ret < 0)
> > +                     goto out_destroy_policy;
> >       }
> >
> >       if (cpufreq_driver->get && has_target()) {
> > --

Re: [PATCH 1/2] cpufreq: Fix re-boost issue after hotplugging a cpu

[zhenglifeng (A)]

On 2025/1/15 20:50, Rafael J. Wysocki wrote:

> On Wed, Jan 15, 2025 at 12:18 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>>
>> On 15-01-25, 18:01, Lifeng Zheng wrote:
>>> It turns out that cpuX will stay on the base frequency after performing
>>> these operations:
>>>
>>> 1. boost all cpus: echo 1 > /sys/devices/system/cpu/cpufreq/boost
>>>
>>> 2. offline the cpu: echo 0 > /sys/devices/system/cpu/cpuX/online
>>>
>>> 3. deboost all cpus: echo 0 > /sys/devices/system/cpu/cpufreq/boost
>>>
>>> 4. online the cpu: echo 1 > /sys/devices/system/cpu/cpuX/online
>>>
>>> 5. boost all cpus again: echo 1 > /sys/devices/system/cpu/cpufreq/boost
>>>
>>> This is because max_freq_req of the policy is not updated during the
>>> online process, and the value of max_freq_req before the last offline is
>>> retained. When the CPU is boosted again, freq_qos_update_request() will
>>> do nothing because the old value is the same as the new one. This causes
>>> the CPU stay on the base frequency. Update max_freq_req (and
>>> min_freq_req of course) in cpufreq_online() will solve this problem.
>>>
>>> Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
>>> ---
>>>  drivers/cpufreq/cpufreq.c | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>>> index 1a4cae54a01b..03ae879d50b9 100644
>>> --- a/drivers/cpufreq/cpufreq.c
>>> +++ b/drivers/cpufreq/cpufreq.c
>>> @@ -1475,6 +1475,13 @@ static int cpufreq_online(unsigned int cpu)
>>>
>>>               blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
>>>                               CPUFREQ_CREATE_POLICY, policy);
>>> +     } else {
>>> +             ret = freq_qos_update_request(policy->min_freq_req, policy->min);
>>
>> This may not be required, as min-freq-req is never updated.
> 
> It gets updated via scaling_min_freq AFAICS.  Doesn't this matter?

If fact, scaling_min_freq cannot be operated when a cpu is offline. So this
update may indeed be unnecessary.

> 
>>> +             if (ret < 0)
>>> +                     goto out_destroy_policy;
>>> +             ret = freq_qos_update_request(policy->max_freq_req, policy->max);
>>> +             if (ret < 0)
>>> +                     goto out_destroy_policy;
>>>       }
>>>
>>>       if (cpufreq_driver->get && has_target()) {
>>> --

[PATCH 2/2] cpufreq: Introduce a more generic way to set default per-policy boost flag

[Lifeng Zheng]

In cpufreq_online() of cpufreq.c, the per-policy boost flag is already set
to mirror the cpufreq_driver boost during init but using freq_table to
judge if the policy has boost frequency. There are two drawbacks to this
approach:

1. It doesn't work for the cpufreq drivers that do not use a frequency
table. For now, acpi-cpufreq and amd-pstate have to enable boost in policy
initialization. And cppc_cpufreq never set policy to boost when going
online no matter what the cpufreq_driver boost flag is.

2. If the cpu goes offline when cpufreq_driver boost enabled and then goes
online when cpufreq_driver boost disabled, the per-policy boost flag will
unreasonably remain true.

Running set_boost at the end of the online process is a more generic way
for all cpufreq drivers.

Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
---
 drivers/cpufreq/cpufreq.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 03ae879d50b9..867bda3decfd 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1409,10 +1409,6 @@ static int cpufreq_online(unsigned int cpu)
 			goto out_free_policy;
 		}
 
-		/* Let the per-policy boost flag mirror the cpufreq_driver boost during init */
-		if (cpufreq_boost_enabled() && policy_has_boost_freq(policy))
-			policy->boost_enabled = true;
-
 		/*
 		 * The initialization has succeeded and the policy is online.
 		 * If there is a problem with its frequency table, take it
@@ -1576,6 +1572,18 @@ static int cpufreq_online(unsigned int cpu)
 	if (new_policy && cpufreq_thermal_control_enabled(cpufreq_driver))
 		policy->cdev = of_cpufreq_cooling_register(policy);
 
+	/* Let the per-policy boost flag mirror the cpufreq_driver boost during init */
+	if (cpufreq_boost_supported()) {
+		policy->boost_enabled = cpufreq_boost_enabled();
+		ret = cpufreq_driver->set_boost(policy, policy->boost_enabled);
+		if (ret) {
+			/* If the set_boost fails, the online operation is not affected */
+			pr_info("%s: CPU%d: Cannot %s BOOST\n", __func__, policy->cpu,
+				policy->boost_enabled ? "enable" : "disable");
+			policy->boost_enabled = !policy->boost_enabled;
+		}
+	}
+
 	pr_debug("initialization complete\n");
 
 	return 0;
-- 
2.33.0

Re: [PATCH 2/2] cpufreq: Introduce a more generic way to set default per-policy boost flag

[Viresh Kumar]

On 15-01-25, 18:01, Lifeng Zheng wrote:
> In cpufreq_online() of cpufreq.c, the per-policy boost flag is already set
> to mirror the cpufreq_driver boost during init but using freq_table to
> judge if the policy has boost frequency. There are two drawbacks to this
> approach:
> 
> 1. It doesn't work for the cpufreq drivers that do not use a frequency
> table. For now, acpi-cpufreq and amd-pstate have to enable boost in policy
> initialization. And cppc_cpufreq never set policy to boost when going
> online no matter what the cpufreq_driver boost flag is.
> 
> 2. If the cpu goes offline when cpufreq_driver boost enabled and then goes
> online when cpufreq_driver boost disabled, the per-policy boost flag will
> unreasonably remain true.

Yeah, this is a problem. I agree. If the global boost is disabled,
then boost shouldn't be allowed for any of the policies.

> Running set_boost at the end of the online process is a more generic way
> for all cpufreq drivers.
> 
> Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
> ---
>  drivers/cpufreq/cpufreq.c | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 03ae879d50b9..867bda3decfd 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1409,10 +1409,6 @@ static int cpufreq_online(unsigned int cpu)
>  			goto out_free_policy;
>  		}
>  
> -		/* Let the per-policy boost flag mirror the cpufreq_driver boost during init */
> -		if (cpufreq_boost_enabled() && policy_has_boost_freq(policy))
> -			policy->boost_enabled = true;
> -
>  		/*
>  		 * The initialization has succeeded and the policy is online.
>  		 * If there is a problem with its frequency table, take it
> @@ -1576,6 +1572,18 @@ static int cpufreq_online(unsigned int cpu)
>  	if (new_policy && cpufreq_thermal_control_enabled(cpufreq_driver))
>  		policy->cdev = of_cpufreq_cooling_register(policy);
>  
> +	/* Let the per-policy boost flag mirror the cpufreq_driver boost during init */
> +	if (cpufreq_boost_supported()) {
> +		policy->boost_enabled = cpufreq_boost_enabled();
> +		ret = cpufreq_driver->set_boost(policy, policy->boost_enabled);

Maybe we can optimize here and not call set_boost() if policy's
boost_enabled is not changing at all.
        if (policy->boost_enabled != cpufreq_boost_enabled()) {
                policy->boost_enabled = cpufreq_boost_enabled();
                ret = cpufreq_driver->set_boost(policy, policy->boost_enabled);
                ...
        }

After this patch, maybe you should simplify the drivers as well, which
take care of enabling/boost at boot time or setting this flag ?

> +		if (ret) {
> +			/* If the set_boost fails, the online operation is not affected */
> +			pr_info("%s: CPU%d: Cannot %s BOOST\n", __func__, policy->cpu,
> +				policy->boost_enabled ? "enable" : "disable");
> +			policy->boost_enabled = !policy->boost_enabled;
> +		}
> +	}
> +
>  	pr_debug("initialization complete\n");
>  
>  	return 0;

-- 
viresh

Re: [PATCH 2/2] cpufreq: Introduce a more generic way to set default per-policy boost flag

[zhenglifeng (A)]

On 2025/1/16 14:54, Viresh Kumar wrote:

> On 15-01-25, 18:01, Lifeng Zheng wrote:
>> In cpufreq_online() of cpufreq.c, the per-policy boost flag is already set
>> to mirror the cpufreq_driver boost during init but using freq_table to
>> judge if the policy has boost frequency. There are two drawbacks to this
>> approach:
>>
>> 1. It doesn't work for the cpufreq drivers that do not use a frequency
>> table. For now, acpi-cpufreq and amd-pstate have to enable boost in policy
>> initialization. And cppc_cpufreq never set policy to boost when going
>> online no matter what the cpufreq_driver boost flag is.
>>
>> 2. If the cpu goes offline when cpufreq_driver boost enabled and then goes
>> online when cpufreq_driver boost disabled, the per-policy boost flag will
>> unreasonably remain true.
> 
> Yeah, this is a problem. I agree. If the global boost is disabled,
> then boost shouldn't be allowed for any of the policies.
> 
>> Running set_boost at the end of the online process is a more generic way
>> for all cpufreq drivers.
>>
>> Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
>> ---
>>  drivers/cpufreq/cpufreq.c | 16 ++++++++++++----
>>  1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 03ae879d50b9..867bda3decfd 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -1409,10 +1409,6 @@ static int cpufreq_online(unsigned int cpu)
>>  			goto out_free_policy;
>>  		}
>>  
>> -		/* Let the per-policy boost flag mirror the cpufreq_driver boost during init */
>> -		if (cpufreq_boost_enabled() && policy_has_boost_freq(policy))
>> -			policy->boost_enabled = true;
>> -
>>  		/*
>>  		 * The initialization has succeeded and the policy is online.
>>  		 * If there is a problem with its frequency table, take it
>> @@ -1576,6 +1572,18 @@ static int cpufreq_online(unsigned int cpu)
>>  	if (new_policy && cpufreq_thermal_control_enabled(cpufreq_driver))
>>  		policy->cdev = of_cpufreq_cooling_register(policy);
>>  
>> +	/* Let the per-policy boost flag mirror the cpufreq_driver boost during init */
>> +	if (cpufreq_boost_supported()) {
>> +		policy->boost_enabled = cpufreq_boost_enabled();
>> +		ret = cpufreq_driver->set_boost(policy, policy->boost_enabled);
> 
> Maybe we can optimize here and not call set_boost() if policy's
> boost_enabled is not changing at all.
>         if (policy->boost_enabled != cpufreq_boost_enabled()) {
>                 policy->boost_enabled = cpufreq_boost_enabled();
>                 ret = cpufreq_driver->set_boost(policy, policy->boost_enabled);
>                 ...
>         }

Makes sense. Thanks.

> 
> After this patch, maybe you should simplify the drivers as well, which
> take care of enabling/boost at boot time or setting this flag ?

OK. I'll try to.

> 
>> +		if (ret) {
>> +			/* If the set_boost fails, the online operation is not affected */
>> +			pr_info("%s: CPU%d: Cannot %s BOOST\n", __func__, policy->cpu,
>> +				policy->boost_enabled ? "enable" : "disable");
>> +			policy->boost_enabled = !policy->boost_enabled;
>> +		}
>> +	}
>> +
>>  	pr_debug("initialization complete\n");
>>  
>>  	return 0;
> 

Re: [PATCH 0/2] cpufreq: Introduce a more generic way to boost when cpu is going online

[Rafael J. Wysocki]

On Wed, Jan 15, 2025 at 11:01 AM Lifeng Zheng <zhenglifeng1@huawei.com> wrote:
>
> Since commit f37a4d6b4a2c ("cpufreq: Fix per-policy boost behavior on
> SoCs using cpufreq_boost_set_sw()") and commit 102fa9c4b439 ("cpufreq:
> Allow drivers to advertise boost enabled"), per-policy boost flag has
> already been set to mirror the cpufreq_driver boost during
> initialization. However, the current implementation doesn't work for all
> cpufreq drivers and may fail in certain situation. A more generic
> implementation is needed.

Can you please be more specific here?

What happens, why it happens and why do you think the way to go is to
reimplement this?

Re: [PATCH 0/2] cpufreq: Introduce a more generic way to boost when cpu is going online

[zhenglifeng (A)]

On 2025/1/15 20:53, Rafael J. Wysocki wrote:

> On Wed, Jan 15, 2025 at 11:01 AM Lifeng Zheng <zhenglifeng1@huawei.com> wrote:
>>
>> Since commit f37a4d6b4a2c ("cpufreq: Fix per-policy boost behavior on
>> SoCs using cpufreq_boost_set_sw()") and commit 102fa9c4b439 ("cpufreq:
>> Allow drivers to advertise boost enabled"), per-policy boost flag has
>> already been set to mirror the cpufreq_driver boost during
>> initialization. However, the current implementation doesn't work for all
>> cpufreq drivers and may fail in certain situation. A more generic
>> implementation is needed.
> 
> Can you please be more specific here?
> 
> What happens, why it happens and why do you think the way to go is to
> reimplement this?

I've explained this in commit log of patch 2. But if you think it is better
to palce here too, I'll do that in v2.