mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Nick Piggin <piggin@cyberone.com.au>,
	Rusty Russell <rusty@rustcorp.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: New NUMA scheduler and hotplug CPU
Date: Mon, 26 Jan 2004 23:19:48 -0800	[thread overview]
Message-ID: <361670000.1075187987@[10.10.2.4]> (raw)
In-Reply-To: <4015F9A8.6000801@cyberone.com.au>

> Well lets not worry too much about this for now. We could use
> static arrays and cpu_possible for now until we get a feel
> for what specific architectures want.
> 
> To be honest I haven't seen the hotplug CPU code and I don't
> know about what architectures want to be doing with it, so
> this is my preferred direction just out of ignorance.
> 
> An easy next step toward a dynamic scheme would be just to
> re-init the entire sched domain topology (the generic init uses
> the generic NUMA topology info which will have to be handled
> by these architectures anyway). Modulo a small locking problem.
> 
> There aren't any fundamental design issues (with sched domains)
> that I can see preventing a more dynamic system so we can keep
> that in mind.

Yeah, I talked it over with Rusty some on IRC. I have more of a feeling
why he's trying to do it that way now. However, one other thought occurs
to me ... it'd be good to use the same infrastructure (sched domains)
for the workload management stuff as well (where the domains would be
defined from userspace). That'd also necessitate them being dynamic,
if you think that'd work out as a usage model.

The cpu_possible stuff might work for a first cut at hotplug I guess.
I still think it's ugly though ;-)

M.


  reply	other threads:[~2004-01-27  7:19 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 [this message]
2004-01-27 15:27                 ` Martin J. Bligh
2004-01-28  0:23                   ` Rusty Russell
2004-01-26 23:40       ` Andrew Theurer
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='361670000.1075187987@[10.10.2.4]' \
    --to=mbligh@aracnet.com \
    --cc=linux-kernel@vger.kernel.org \
    --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®