All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: linux-kernel@vger.kernel.org, ralf@gnu.org, rhw@memalpha.cx,
	mingo@redhat.com, paulus@samba.org, anton@samba.org,
	schwidefsky@de.ibm.com, bh@sgi.com, davem@redhat.com, ak@suse.de,
	torvalds@transmeta.com
Subject: Re: Hotplug CPU Boot Changes: BEWARE
Date: 07 Jun 2002 08:51:32 -0600	[thread overview]
Message-ID: <m1elfjw39n.fsf@frodo.biederman.org> (raw)
In-Reply-To: <E17GHB3-0000gD-00@wagner.rustcorp.com.au>

Rusty Russell <rusty@rustcorp.com.au> writes:

> Hi all (esp port maintainers),
> 
> 	In writing the hotplug CPU stuff, Linus asked me to alter the
> boot sequence to "plug in" CPUs.  I am shortly going to be sending
> these patches to him now I have got my x86 box to boot with the
> changes.

If to the general SMP case is added the ability to dynamically enable
and disable cpus at runtime, this infrastructure work appears to have
general applicability now.  Allowing for example dynamic
enable/disable of HT on P4-Xeons at runtime for example.


> There are two ways to transition: one is to do the minimal hacks so
> that the new boot code works (as per my x86 patch).  The other is to
> take into account that the next stage (optional by arch) is to
> actually bring cpus up and down on the fly, and hence actually write
> code that will work after boot as well (as per my ppc patch).

Thinking in terms of physically hot-plugging cpus has me doubt the
actual utility of this code.  Instead thinking of dynamically enabling
and disabling processors for debugging sounds very reasonable.

But for the latter something just a little more than minimal hacks
must be implemented.  But dynamic cpu enable/disable is definitely
worth it.

Eric


  reply	other threads:[~2002-06-07 15:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-07 10:40 Hotplug CPU Boot Changes: BEWARE Rusty Russell
2002-06-07 14:51 ` Eric W. Biederman [this message]
2002-06-02 16:22   ` Pavel Machek
2002-06-08  1:55   ` Keith Owens
2002-06-10  7:05   ` Rusty Russell
2002-06-10 13:43     ` Eric W. Biederman

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=m1elfjw39n.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=ak@suse.de \
    --cc=anton@samba.org \
    --cc=bh@sgi.com \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=ralf@gnu.org \
    --cc=rhw@memalpha.cx \
    --cc=rusty@rustcorp.com.au \
    --cc=schwidefsky@de.ibm.com \
    --cc=torvalds@transmeta.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.