[PATCH] init: Don't decrease loops_per_jiffy when a CPU comes up

[PATCH] init: Don't decrease loops_per_jiffy when a CPU comes up

[Doug Anderson]

The loops_per_jiffy count continues to be updated as each CPU is
brought up.  This causes problems when we've got an HMP system and
different CPUs have different loops per jiffy.  On exynos 542x
systems, for instance, the A7s will have significantly lower loops per
jiffy than their big brothers.

We should always set the loops_per_jiffy the first time through, then
use the max.

One could argue that complex HMP systems should really be completely
ignoring the global loops_per_jiffy variable anyway.  That's probably
why nobody has fixed this before.  With that argument you could say
that while this change isn't incorrect, it's a bit misguided.  Still,
it doesn't hurt and provides a better fallback than we had without
this.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
 init/calibrate.c | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/init/calibrate.c b/init/calibrate.c
index 520702d..073bf9b 100644
--- a/init/calibrate.c
+++ b/init/calibrate.c
@@ -265,40 +265,44 @@ unsigned long __attribute__((weak)) calibrate_delay_is_known(void)
 void calibrate_delay(void)
 {
 	unsigned long lpj;
-	static bool printed;
+	static bool already_ran;
 	int this_cpu = smp_processor_id();
 
 	if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
 		lpj = per_cpu(cpu_loops_per_jiffy, this_cpu);
-		if (!printed)
+		if (!already_ran)
 			pr_info("Calibrating delay loop (skipped) "
 				"already calibrated this CPU");
 	} else if (preset_lpj) {
 		lpj = preset_lpj;
-		if (!printed)
+		if (!already_ran)
 			pr_info("Calibrating delay loop (skipped) "
 				"preset value.. ");
-	} else if ((!printed) && lpj_fine) {
+	} else if ((!already_ran) && lpj_fine) {
 		lpj = lpj_fine;
 		pr_info("Calibrating delay loop (skipped), "
 			"value calculated using timer frequency.. ");
 	} else if ((lpj = calibrate_delay_is_known())) {
 		;
 	} else if ((lpj = calibrate_delay_direct()) != 0) {
-		if (!printed)
+		if (!already_ran)
 			pr_info("Calibrating delay using timer "
 				"specific routine.. ");
 	} else {
-		if (!printed)
+		if (!already_ran)
 			pr_info("Calibrating delay loop... ");
 		lpj = calibrate_delay_converge();
 	}
 	per_cpu(cpu_loops_per_jiffy, this_cpu) = lpj;
-	if (!printed)
+	if (!already_ran) {
 		pr_cont("%lu.%02lu BogoMIPS (lpj=%lu)\n",
 			lpj/(500000/HZ),
 			(lpj/(5000/HZ)) % 100, lpj);
 
-	loops_per_jiffy = lpj;
-	printed = true;
+		loops_per_jiffy = lpj;
+	} else {
+		loops_per_jiffy = max(loops_per_jiffy, lpj);
+	}
+
+	already_ran = true;
 }
-- 
1.9.1.423.g4596e3a

Re: [PATCH] init: Don't decrease loops_per_jiffy when a CPU comes up

[Paul Gortmaker]

On 14-05-07 07:50 PM, Doug Anderson wrote:
> The loops_per_jiffy count continues to be updated as each CPU is
> brought up.  This causes problems when we've got an HMP system and
> different CPUs have different loops per jiffy.  On exynos 542x
> systems, for instance, the A7s will have significantly lower loops per
> jiffy than their big brothers.

Based on the other discussion for the ARM variant of this, I'm
assuming this also becomes a WFC issue.  And if not, then it
probably should go by John or similar ; getmaintainers is just
being dumb in spitting my name out, since I only made one
trivial change to this file a year ago or similar.

P.
--

> 
> We should always set the loops_per_jiffy the first time through, then
> use the max.
> 
> One could argue that complex HMP systems should really be completely
> ignoring the global loops_per_jiffy variable anyway.  That's probably
> why nobody has fixed this before.  With that argument you could say
> that while this change isn't incorrect, it's a bit misguided.  Still,
> it doesn't hurt and provides a better fallback than we had without
> this.
> 
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> ---
>  init/calibrate.c | 22 +++++++++++++---------
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/init/calibrate.c b/init/calibrate.c
> index 520702d..073bf9b 100644
> --- a/init/calibrate.c
> +++ b/init/calibrate.c
> @@ -265,40 +265,44 @@ unsigned long __attribute__((weak)) calibrate_delay_is_known(void)
>  void calibrate_delay(void)
>  {
>  	unsigned long lpj;
> -	static bool printed;
> +	static bool already_ran;
>  	int this_cpu = smp_processor_id();
>  
>  	if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
>  		lpj = per_cpu(cpu_loops_per_jiffy, this_cpu);
> -		if (!printed)
> +		if (!already_ran)
>  			pr_info("Calibrating delay loop (skipped) "
>  				"already calibrated this CPU");
>  	} else if (preset_lpj) {
>  		lpj = preset_lpj;
> -		if (!printed)
> +		if (!already_ran)
>  			pr_info("Calibrating delay loop (skipped) "
>  				"preset value.. ");
> -	} else if ((!printed) && lpj_fine) {
> +	} else if ((!already_ran) && lpj_fine) {
>  		lpj = lpj_fine;
>  		pr_info("Calibrating delay loop (skipped), "
>  			"value calculated using timer frequency.. ");
>  	} else if ((lpj = calibrate_delay_is_known())) {
>  		;
>  	} else if ((lpj = calibrate_delay_direct()) != 0) {
> -		if (!printed)
> +		if (!already_ran)
>  			pr_info("Calibrating delay using timer "
>  				"specific routine.. ");
>  	} else {
> -		if (!printed)
> +		if (!already_ran)
>  			pr_info("Calibrating delay loop... ");
>  		lpj = calibrate_delay_converge();
>  	}
>  	per_cpu(cpu_loops_per_jiffy, this_cpu) = lpj;
> -	if (!printed)
> +	if (!already_ran) {
>  		pr_cont("%lu.%02lu BogoMIPS (lpj=%lu)\n",
>  			lpj/(500000/HZ),
>  			(lpj/(5000/HZ)) % 100, lpj);
>  
> -	loops_per_jiffy = lpj;
> -	printed = true;
> +		loops_per_jiffy = lpj;
> +	} else {
> +		loops_per_jiffy = max(loops_per_jiffy, lpj);
> +	}
> +
> +	already_ran = true;
>  }
> 

Re: [PATCH] init: Don't decrease loops_per_jiffy when a CPU comes up

[Doug Anderson]

Paul,

On Fri, May 9, 2014 at 9:03 AM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> On 14-05-07 07:50 PM, Doug Anderson wrote:
>> The loops_per_jiffy count continues to be updated as each CPU is
>> brought up.  This causes problems when we've got an HMP system and
>> different CPUs have different loops per jiffy.  On exynos 542x
>> systems, for instance, the A7s will have significantly lower loops per
>> jiffy than their big brothers.
>
> Based on the other discussion for the ARM variant of this, I'm
> assuming this also becomes a WFC issue.  And if not, then it
> probably should go by John or similar ; getmaintainers is just
> being dumb in spitting my name out, since I only made one
> trivial change to this file a year ago or similar.

I think this change could still make sense.  The ARM discussion is
about dealing with the scaling that the ARM code does, but it really
is a separate concept.

In general it seems like at least a warning is in order if
loops_per_jiffy changes significantly from CPU to CPU.