public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Nathan Lynch <nathanl@austin.ibm.com>
Cc: Jesse Barnes <jbarnes@engr.sgi.com>,
	Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
	Matthew Dobson <colpatch@us.ibm.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: SMP Panic caused by [PATCH] sched: consolidate sched domains
Date: 29 Aug 2004 18:59:49 -0400	[thread overview]
Message-ID: <1093820392.1708.73.camel@mulgrave> (raw)
In-Reply-To: <1093801714.29741.15.camel@booger>

On Sun, 2004-08-29 at 13:48, Nathan Lynch wrote:
> I've got a patch which reinitializes sched domains at cpu hotplug time. 
> We need something like this on ppc64 for partitioned systems (we run
> into the same issue when adding a cpu which wasn't present at boot).  I
> had been waiting to post it until some cpu hotplug issues with preempt
> were solved, but it seems it would help the case of hotplugging
> secondary cpus at boot, so I'll submit that soon.

Well, but the only time you should need to alter a priori knowledge like
this is if you're actually altering the NUMA topology, isn't it?  Simply
bringing up a CPU in a known numa system shouldn't need to alter
scheduling domain information on CPU hotplug because the cpu
automatically becomes part of an existing domain (where it was
originally accounted for as missing).

However, if you hotplug a numa node, then you're adding to the
scheduling domain and would thus need to initialise the new node and its
CPUs.

James



  reply	other threads:[~2004-08-29 23:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-29 13:39 SMP Panic caused by [PATCH] sched: consolidate sched domains James Bottomley
2004-08-29 16:48 ` Jesse Barnes
2004-08-29 16:58   ` James Bottomley
2004-08-29 17:07     ` Jesse Barnes
2004-08-29 17:16       ` James Bottomley
2004-08-30 19:11         ` Matthew Dobson
2004-08-29 17:24       ` James Bottomley
2004-08-29 17:48         ` Nathan Lynch
2004-08-29 22:59           ` James Bottomley [this message]
2004-08-29 17:03   ` William Lee Irwin III
2004-08-29 17:09     ` James Bottomley
2004-08-29 17:22       ` William Lee Irwin III
2004-08-29 17:29         ` William Lee Irwin III
2004-08-29 17:40           ` William Lee Irwin III
2004-08-29 17:50             ` William Lee Irwin III
2004-08-29 23:13               ` James Bottomley

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=1093820392.1708.73.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=akpm@osdl.org \
    --cc=colpatch@us.ibm.com \
    --cc=jbarnes@engr.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nathanl@austin.ibm.com \
    --cc=nickpiggin@yahoo.com.au \
    --cc=torvalds@osdl.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox