All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <piggin@cyberone.com.au>
To: "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: Tue, 27 Jan 2004 10:01:21 +1100	[thread overview]
Message-ID: <40159C41.9030707@cyberone.com.au> (raw)
In-Reply-To: <315060000.1075134874@[10.10.2.4]>



Martin J. Bligh wrote:

>>>	Looking at your new scheduler in -mm, it uses cpu_online_map
>>>alot in arch_init_sched_domains.  This means with hotplug CPU that it
>>>would need to be modified: certainly possible to do, but messy.
>>>
>>>	The other option is to use cpu_possible_map to create the full
>>>topology up front, and then it need never change.  AFAICT, no other
>>>changes are neccessary: you already check against moving tasks to
>>>offline cpus.
>>>
>>>Anyway, I was just porting the hotplug CPU patches over to -mm, and
>>>came across this, so I thought I'd ask.
>>>
>>>
>>Hi Rusty,
>>Yes I'd like to use the cpu_possible_map to create the full
>>topology straight up. Martin?
>>
>
>Well isn't it a bad idea to have cpus in the data that are offline?
>It'll throw off all your balancing calculations, won't it? You seemed
>to be careful to do things like divide the total load on the node by
>the number of CPUs on the node, and that'll get totally borked if you
>have fake CPUs in there.
>

I think it mostly does a good job at making sure to only take
online cpus into account. If there are places where it doesn't
then it shouldn't be too hard to fix.


>
>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.



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

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-25 23:50 New NUMA scheduler and hotplug CPU Rusty Russell
2004-01-26  8:26 ` Nick Piggin
2004-01-26 16:34   ` Martin J. Bligh
2004-01-26 23:01     ` Nick Piggin [this message]
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
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=40159C41.9030707@cyberone.com.au \
    --to=piggin@cyberone.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --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 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.