mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Theurer <habanero@us.ibm.com>
To: Nick Piggin <piggin@cyberone.com.au>,
	"Martin J. Bligh" <mbligh@aracnet.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org
Subject: Re: New NUMA scheduler and hotplug CPU
Date: Mon, 26 Jan 2004 17:40:12 -0600	[thread overview]
Message-ID: <200401261740.12657.habanero@us.ibm.com> (raw)
In-Reply-To: <40159C41.9030707@cyberone.com.au>

> >To me, it'd make more sense to add the CPUs to the scheduler structures
> >as they get brought online. I can also imagine machines where you have
> >a massive (infinite?) variety of possible CPUs that could appear -
> >like an NUMA box where you could just plug arbitrary numbers of new
> >nodes in as you wanted.
>
> I guess so, but you'd still need NR_CPUS to be >= that arbitrary
> number.
>
> >Moreover, as the CPUs aren't fixed numbers in advance, how are you going
> >to know which node to put them in, etc? Setting up every possible thing
> >in advance seems like an infeasible way to do hotplug to me.
>
> Well this would be the problem. I guess its quite possible that
> one doesn't know the topology of newly added CPUs before hand.
>
> Well OK, this would require a per architecture function to handle
> CPU hotplug. It could possibly just default to arch_init_sched_domains,
> and just completely reinitialise everything which would be the simplest.

Call me crazy, but why not let the topology be determined via userspace at a 
more appropriate time?  When you hotplug, you tell it where in the scheduler 
to plug it.  Have structures in the scheduler which represent the 
nodes-runqueues-cpus topology (in the past I tried a node/rq/cpu structs with 
simple pointers), but let the topology be built based on user's desires thru 
hotplug.  

For example, you boot on just the boot cpu, which by default is in the first 
node on the first runqueue.  All other cpus, whether being "booted" for the 
for the first time or hotplugged (maybe now there's really no difference), 
the hotplugging tells where the cpu should be, in what node and what 
runqueue.  HT cpus work even better, because you can hotplug siblings, once 
at a time if you wanted, to the same runqueue.  Or you have cpus sharing a 
die, same thing, lots of choices here.  This removes any per-arch updates to 
the kernel for things like scheduler topology, and lets them go somewhere 
else more easily changes, like userspace. 

Forgive me if this sounds stupid; I have not been following the discussion 
closely.




  parent reply	other threads:[~2004-01-26 23:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-25 23:50 Rusty Russell
2004-01-26  8:26 ` Nick Piggin
2004-01-26 16:34   ` Martin J. Bligh
2004-01-26 23:01     ` Nick Piggin
2004-01-26 23:24       ` Martin J. Bligh
2004-01-26 23:40         ` Nick Piggin
2004-01-27  2:36         ` Rusty Russell
2004-01-27  4:38           ` Martin J. Bligh
2004-01-27  5:39             ` Nick Piggin
2004-01-27  7:19               ` Martin J. Bligh
2004-01-27 15:27                 ` Martin J. Bligh
2004-01-28  0:23                   ` Rusty Russell
2004-01-26 23:40       ` Andrew Theurer [this message]
2004-01-27  0:07         ` Nick Piggin
2004-01-27  2:21           ` Andrew Theurer
2004-01-27  2:40             ` Nick Piggin
2004-01-27  0:09         ` Martin J. Bligh
2004-01-27  2:19           ` Andrew Theurer

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=200401261740.12657.habanero@us.ibm.com \
    --to=habanero@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --cc=piggin@cyberone.com.au \
    --cc=rusty@rustcorp.com.au \
    /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

all inboxes | Powered by JetHome®