diff mbox series

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

Message ID 20250115100123.241110-2-zhenglifeng1@huawei.com (mailing list archive)
State New
Headers show
Series cpufreq: Introduce a more generic way to boost when cpu is going online | expand

Commit Message

Lifeng Zheng Jan. 15, 2025, 10:01 a.m. UTC
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(+)

Comments

Viresh Kumar Jan. 15, 2025, 11:18 a.m. UTC | #1
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
Rafael J. Wysocki Jan. 15, 2025, 12:50 p.m. UTC | #2
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()) {
> > --
diff mbox series

Patch

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()) {