From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
mikey@neuling.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
gregkh@linuxfoundation.org,
ppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-kernel@vger.kernel.org, Milton Miller <miltonm@bga.com>,
Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
"H. Peter Anvin" <hpa@zytor.com>,
arjanvandeven@gmail.com, Ingo Molnar <mingo@elte.hu>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: smp: Start up non-boot CPUs asynchronously
Date: Wed, 15 Feb 2012 08:28:20 +1100 [thread overview]
Message-ID: <1329254900.3772.10.camel@pasglop> (raw)
In-Reply-To: <4F3A2DFB.5000209@linux.vnet.ibm.com>
On Tue, 2012-02-14 at 15:18 +0530, Srivatsa S. Bhat wrote:
> > 2. Just below that we have smp_cpus_done(setup_max_cpus); and this translates
> > to native_smp_cpus_done() under x86, which calls impress_friends().
> > And that means, the bogosum calculation and the total activated processor
> > count which is printed, may get messed up.
We also have code on powerpc that relies on the bringup having been
completed in smp_cpus_done(), especially on platforms that don't support
CPU hotplug (or fake it using sleep loops).
In some case we unmap MMIO space or close access to components (i2c for
example) that we use during the bringup for things like hard synchro of
CPU timebases, etc... on some G5s we disable the elastic interface on
the northbridge for CPUs that weren't brought up, that sort of thing...
So this patch will break a LOT of stuff for us, it must at least be a
config option for now, until we find another way to fix these things.
Cheers,
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
mikey@neuling.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
gregkh@linuxfoundation.org, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org, Milton Miller <miltonm@bga.com>,
Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
"H. Peter Anvin" <hpa@zytor.com>,
arjanvandeven@gmail.com, Thomas Gleixner <tglx@linutronix.de>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
ppc-dev <linuxppc-dev@lists.ozlabs.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Subject: Re: smp: Start up non-boot CPUs asynchronously
Date: Wed, 15 Feb 2012 08:28:20 +1100 [thread overview]
Message-ID: <1329254900.3772.10.camel@pasglop> (raw)
In-Reply-To: <4F3A2DFB.5000209@linux.vnet.ibm.com>
On Tue, 2012-02-14 at 15:18 +0530, Srivatsa S. Bhat wrote:
> > 2. Just below that we have smp_cpus_done(setup_max_cpus); and this translates
> > to native_smp_cpus_done() under x86, which calls impress_friends().
> > And that means, the bogosum calculation and the total activated processor
> > count which is printed, may get messed up.
We also have code on powerpc that relies on the bringup having been
completed in smp_cpus_done(), especially on platforms that don't support
CPU hotplug (or fake it using sleep loops).
In some case we unmap MMIO space or close access to components (i2c for
example) that we use during the bringup for things like hard synchro of
CPU timebases, etc... on some G5s we disable the elastic interface on
the northbridge for CPUs that weren't brought up, that sort of thing...
So this patch will break a LOT of stuff for us, it must at least be a
config option for now, until we find another way to fix these things.
Cheers,
Ben.
next prev parent reply other threads:[~2012-02-14 21:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-31 4:54 smp: Start up non-boot CPUs asynchronously Arjan van de Ven
2012-01-31 12:52 ` Ingo Molnar
2012-01-31 13:41 ` Arjan van de Ven
2012-01-31 14:31 ` Ingo Molnar
2012-01-31 15:22 ` Arjan van de Ven
2012-01-31 16:12 ` Ingo Molnar
2012-01-31 16:24 ` Arjan van de Ven
2012-02-01 22:55 ` Andrew Morton
[not found] ` <CADyApD0yVOePmaLznks_h6xR_BCUjzEFUB7VtsL9vvsoHwCOVw@mail.gmail.com>
2012-02-01 23:31 ` Linus Torvalds
2012-02-14 8:17 ` Srivatsa S. Bhat
2012-02-14 8:17 ` Srivatsa S. Bhat
2012-02-14 9:48 ` Srivatsa S. Bhat
2012-02-14 9:48 ` Srivatsa S. Bhat
2012-02-14 14:31 ` Arjan van de Ven
2012-02-14 15:20 ` Peter Zijlstra
2012-02-14 15:20 ` Peter Zijlstra
2012-02-14 16:01 ` Arjan van de Ven
2012-02-14 19:57 ` Srivatsa S. Bhat
2012-02-14 19:57 ` Srivatsa S. Bhat
2012-02-14 20:00 ` Peter Zijlstra
2012-02-14 20:00 ` Peter Zijlstra
2012-02-14 21:02 ` Arjan van de Ven
2012-02-14 21:02 ` Arjan van de Ven
2012-02-14 19:32 ` Srivatsa S. Bhat
2012-02-14 19:32 ` Srivatsa S. Bhat
2012-02-14 21:28 ` Benjamin Herrenschmidt [this message]
2012-02-14 21:28 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1329254900.3772.10.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=arjanvandeven@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mikey@neuling.org \
--cc=miltonm@bga.com \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--cc=sfr@canb.auug.org.au \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vatsa@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.