Re: [PATCH] init: Don't decrease loops_per_jiffy when a CPU comes up
Paul, On Fri, May 9, 2014 at 9:03 AM, Paul Gortmaker 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] init: Don't decrease loops_per_jiffy when a CPU comes up
Paul, On Fri, May 9, 2014 at 9:03 AM, Paul Gortmaker paul.gortma...@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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] init: Don't decrease loops_per_jiffy when a CPU comes up
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
> ---
> 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/(50/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;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] init: Don't decrease loops_per_jiffy when a CPU comes up
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 diand...@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/(50/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;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] init: Don't decrease loops_per_jiffy when a CPU comes up
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
---
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/(50/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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] init: Don't decrease loops_per_jiffy when a CPU comes up
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 diand...@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/(50/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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
