diff mbox series

[v3] cpufreq: schedutil: Examine the correct CPU when we update util

Message ID 20171103133642.8636-1-chris.redpath@arm.com
State New
Headers show
Series [v3] cpufreq: schedutil: Examine the correct CPU when we update util | expand

Commit Message

Chris Redpath Nov. 3, 2017, 1:36 p.m. UTC
After
674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks")

We stopped always reading utilization for the cpu we are running
the governor on, and instead read it for the cpu which we've been
told has updated utilization. This is stored in sugov_cpu->cpu.

The value is set in sugov_register but we clear it in sugov_start
which leads to always looking at the utilization of CPU0 instead
of the correct one.

Let's fix this by consolidating the initialization code into
sugov_start().

Fixes: 674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks")
Signed-off-by: Chris Redpath <chris.redpath@arm.com>

Reviewed-by: Patrick Bellasi <patrick.bellasi@arm.com>

Reviewed-by: Brendan Jackman <brendan.jackman@arm.com>

Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
---
 kernel/sched/cpufreq_schedutil.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

-- 
2.13.1.449.g02a2850

Comments

Viresh Kumar Nov. 3, 2017, 3:45 p.m. UTC | #1
On 03-11-17, 13:36, Chris Redpath wrote:
> After

> 674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks")

> 

> We stopped always reading utilization for the cpu we are running

> the governor on, and instead read it for the cpu which we've been

> told has updated utilization. This is stored in sugov_cpu->cpu.

> 

> The value is set in sugov_register but we clear it in sugov_start

> which leads to always looking at the utilization of CPU0 instead

> of the correct one.

> 

> Let's fix this by consolidating the initialization code into

> sugov_start().

> 

> Fixes: 674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks")

> Signed-off-by: Chris Redpath <chris.redpath@arm.com>

> Reviewed-by: Patrick Bellasi <patrick.bellasi@arm.com>

> Reviewed-by: Brendan Jackman <brendan.jackman@arm.com>

> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>

> Cc: Viresh Kumar <viresh.kumar@linaro.org>

> Cc: Ingo Molnar <mingo@redhat.com>

> Cc: Peter Zijlstra <peterz@infradead.org>

> ---

>  kernel/sched/cpufreq_schedutil.c | 6 +-----

>  1 file changed, 1 insertion(+), 5 deletions(-)


Acked-by: Viresh Kumar <viresh.kumar@linaro.org>


-- 
viresh
Chris Redpath Nov. 7, 2017, 9:49 a.m. UTC | #2
Hi Viresh, Rafael,

Without this patch, schedutil is totally broken for us - is
there any chance at all this could go in 4.14 or is it just
too late?

Best Regards,
Chris

On 03/11/17 15:45, Viresh Kumar wrote:
> On 03-11-17, 13:36, Chris Redpath wrote:

>> After

>> 674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks")

>>

>> We stopped always reading utilization for the cpu we are running

>> the governor on, and instead read it for the cpu which we've been

>> told has updated utilization. This is stored in sugov_cpu->cpu.

>>

>> The value is set in sugov_register but we clear it in sugov_start

>> which leads to always looking at the utilization of CPU0 instead

>> of the correct one.

>>

>> Let's fix this by consolidating the initialization code into

>> sugov_start().

>>

>> Fixes: 674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks")

>> Signed-off-by: Chris Redpath <chris.redpath@arm.com>

>> Reviewed-by: Patrick Bellasi <patrick.bellasi@arm.com>

>> Reviewed-by: Brendan Jackman <brendan.jackman@arm.com>

>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>

>> Cc: Viresh Kumar <viresh.kumar@linaro.org>

>> Cc: Ingo Molnar <mingo@redhat.com>

>> Cc: Peter Zijlstra <peterz@infradead.org>

>> ---

>>   kernel/sched/cpufreq_schedutil.c | 6 +-----

>>   1 file changed, 1 insertion(+), 5 deletions(-)

>

> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Viresh Kumar Nov. 7, 2017, 9:59 a.m. UTC | #3
On 07-11-17, 09:49, Chris Redpath wrote:
> Hi Viresh, Rafael,

> 

> Without this patch, schedutil is totally broken for us - is

> there any chance at all this could go in 4.14 or is it just

> too late?


I see that Rafael has already applied it, but not sure if he is planning to send
it for 4.14 (though he should IMHO, as it is a critical fix).

commit d62d813c0d71 ("cpufreq: schedutil: Examine the correct CPU when we update
util")

--
viresh
Rafael J. Wysocki Nov. 7, 2017, 10:09 a.m. UTC | #4
On Tue, Nov 7, 2017 at 10:59 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 07-11-17, 09:49, Chris Redpath wrote:

>> Hi Viresh, Rafael,

>>

>> Without this patch, schedutil is totally broken for us - is

>> there any chance at all this could go in 4.14 or is it just

>> too late?

>

> I see that Rafael has already applied it, but not sure if he is planning to send

> it for 4.14 (though he should IMHO, as it is a critical fix).


Yes, I am.

Thanks,
Rafael
Chris Redpath Nov. 7, 2017, 11:03 a.m. UTC | #5
Thanks guys, really appreciated!

--Chris

On 07/11/17 10:09, Rafael J. Wysocki wrote:
> On Tue, Nov 7, 2017 at 10:59 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:

>> On 07-11-17, 09:49, Chris Redpath wrote:

>>> Hi Viresh, Rafael,

>>>

>>> Without this patch, schedutil is totally broken for us - is

>>> there any chance at all this could go in 4.14 or is it just

>>> too late?

>>

>> I see that Rafael has already applied it, but not sure if he is planning to send

>> it for 4.14 (though he should IMHO, as it is a critical fix).

> 

> Yes, I am.

> 

> Thanks,

> Rafael

>
diff mbox series

Patch

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 6c1a7fcfa2a7..dc68a1ccdb33 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -728,6 +728,7 @@  static int sugov_start(struct cpufreq_policy *policy)
 		struct sugov_cpu *sg_cpu = &per_cpu(sugov_cpu, cpu);
 
 		memset(sg_cpu, 0, sizeof(*sg_cpu));
+		sg_cpu->cpu = cpu;
 		sg_cpu->sg_policy = sg_policy;
 		sg_cpu->flags = SCHED_CPUFREQ_RT;
 		sg_cpu->iowait_boost_max = policy->cpuinfo.max_freq;
@@ -793,11 +794,6 @@  struct cpufreq_governor *cpufreq_default_governor(void)
 
 static int __init sugov_register(void)
 {
-	int cpu;
-
-	for_each_possible_cpu(cpu)
-		per_cpu(sugov_cpu, cpu).cpu = cpu;
-
 	return cpufreq_register_governor(&schedutil_gov);
 }
 fs_initcall(sugov_register);