All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@linux.intel.com>
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
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>,
	Arjan van de Ven <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>,
	Arjan van de Ven <arjan@infradead.org>
Subject: Re: smp: Start up non-boot CPUs asynchronously
Date: Tue, 14 Feb 2012 13:02:58 -0800	[thread overview]
Message-ID: <4F3ACC02.9020003@linux.intel.com> (raw)
In-Reply-To: <4F3ABCC1.5020000@linux.vnet.ibm.com>

On 2/14/2012 11:57 AM, Srivatsa S. Bhat wrote:

>> In addition to this, the reality is that the whole "bring cpus up"
>> sequence needs to be changed; the current one is very messy and requires
>> the hotplug lock for the whole bring up of each individual cpu... which
>> is a very unfortunate design; a much better design would be to only take
>> the lock for the actual registration of the newly brought up CPU to the
>> kernel, while running the physical bringup without the global lock.
>> If/when that change gets made, we can do the physical bring up in
>> parallel (with each other, but also with the rest of the kernel boot),
>> and do the registration en-mass at some convenient time in the boot,
>> potentially late.
>>
> 
> 
> Sounds like a good idea, but how will we take care of CPU_UP_PREPARE and
> CPU_STARTING callbacks then? Because, CPU_UP_PREPARE callbacks are run
> before bringing up the cpu and CPU_STARTING is called from the cpu that is
> coming up. Also, CPU_UP_PREPARE callbacks can be failed, which can lead
> to that particular cpu boot getting aborted. With the "late commissioning
> of CPUs" idea you proposed above, retaining such semantics could become
> very challenging.

some of these callbacks may need to be redesigned as well; or at least,
we may need to decouple the "physical" state of the CPU that's getting
brought up from the "logical" OS visible one.

WARNING: multiple messages have this Message-ID (diff)
From: Arjan van de Ven <arjan@linux.intel.com>
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Arjan van de Ven <arjanvandeven@gmail.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	mikey@neuling.org,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	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>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: smp: Start up non-boot CPUs asynchronously
Date: Tue, 14 Feb 2012 13:02:58 -0800	[thread overview]
Message-ID: <4F3ACC02.9020003@linux.intel.com> (raw)
In-Reply-To: <4F3ABCC1.5020000@linux.vnet.ibm.com>

On 2/14/2012 11:57 AM, Srivatsa S. Bhat wrote:

>> In addition to this, the reality is that the whole "bring cpus up"
>> sequence needs to be changed; the current one is very messy and requires
>> the hotplug lock for the whole bring up of each individual cpu... which
>> is a very unfortunate design; a much better design would be to only take
>> the lock for the actual registration of the newly brought up CPU to the
>> kernel, while running the physical bringup without the global lock.
>> If/when that change gets made, we can do the physical bring up in
>> parallel (with each other, but also with the rest of the kernel boot),
>> and do the registration en-mass at some convenient time in the boot,
>> potentially late.
>>
> 
> 
> Sounds like a good idea, but how will we take care of CPU_UP_PREPARE and
> CPU_STARTING callbacks then? Because, CPU_UP_PREPARE callbacks are run
> before bringing up the cpu and CPU_STARTING is called from the cpu that is
> coming up. Also, CPU_UP_PREPARE callbacks can be failed, which can lead
> to that particular cpu boot getting aborted. With the "late commissioning
> of CPUs" idea you proposed above, retaining such semantics could become
> very challenging.

some of these callbacks may need to be redesigned as well; or at least,
we may need to decouple the "physical" state of the CPU that's getting
brought up from the "logical" OS visible one.

  parent reply	other threads:[~2012-02-14 21:03 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 [this message]
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
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=4F3ACC02.9020003@linux.intel.com \
    --to=arjan@linux.intel.com \
    --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.