[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120601091201.31979.37258.stgit@srivatsabhat.in.ibm.com>
Date: Fri, 01 Jun 2012 14:42:11 +0530
From: "Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To: tglx@...utronix.de, peterz@...radead.org,
paulmck@...ux.vnet.ibm.com
Cc: rusty@...tcorp.com.au, mingo@...nel.org, yong.zhang0@...il.com,
akpm@...ux-foundation.org, vatsa@...ux.vnet.ibm.com, rjw@...k.pl,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
srivatsa.bhat@...ux.vnet.ibm.com, nikunj@...ux.vnet.ibm.com,
Hirokazu Takata <takata@...ux-m32r.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-m32r@...linux-m32r.org, linux-m32r-ja@...linux-m32r.org
Subject: [PATCH 08/27] m32r: Fix horrible logic in smp_prepare_cpus()
In smp_prepare_cpus(), after max_cpus are booted, instead of breaking
from the loop, the 'continue' statement is used which results in unnecessarily
wasting time by looping NR_CPUS times!
Many things around this could be pulled into generic code in the future, but
for now, fix this particular piece of code locally (because I am unable to
convince myself to ignore it even temporarily, given that it is such a gem!).
And also rewrite the 'if' statement in a more natural way.
Cc: Hirokazu Takata <takata@...ux-m32r.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: linux-m32r@...linux-m32r.org
Cc: linux-m32r-ja@...linux-m32r.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@...ux.vnet.ibm.com>
---
arch/m32r/kernel/smpboot.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/m32r/kernel/smpboot.c b/arch/m32r/kernel/smpboot.c
index a2cfc0a..6ddc51a 100644
--- a/arch/m32r/kernel/smpboot.c
+++ b/arch/m32r/kernel/smpboot.c
@@ -209,8 +209,8 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
if (!physid_isset(phys_id, phys_cpu_present_map))
continue;
- if (max_cpus <= cpucount + 1)
- continue;
+ if (cpucount + 1 >= max_cpus)
+ break;
do_boot_cpu(phys_id);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists