From: Ingo Molnar <mingo@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org,
Nick Piggin <piggin@cyberone.com.au>,
dipankar@in.ibm.com, vatsa@in.ibm.com
Subject: Re: [PATCH 3/4] 2.6.2-rc2-mm2 CPU Hotplug: The Core
Date: Mon, 2 Feb 2004 04:12:34 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.58.0402020353240.25194@devserv.devel.redhat.com> (raw)
In-Reply-To: <20040131141937.E58852C082@lists.samba.org>
On Sun, 1 Feb 2004, Rusty Russell wrote:
> D: - kernel/sched.c: Add wake_idle_cpu() for i386 hotplug.
> D:
> D: Check everywhere to make sure we never move tasks onto an
> D: offline cpu: we'll just be fighting migrate_all_tasks().
> D:
> D: Change sched_migrate_task() to migrate_to_cpu and expose it
> D: for hotplug cpu.
> D:
> D: Take hotplug lock in sys_sched_setaffinity.
> D:
> D: Return cpus_allowed masked by cpu_possible_map, not
> D: cpu_online_map in sys_sched_getaffinity, otherwise tasks can't
> D: know about whether they can run on currently-offline cpus.
> D:
> D: Implement migrate_all_tasks() to push tasks off the dying cpu.
> D:
> D: Add callbacks to stop migration thread.
the sched.c bits look good. A question: why is the migrate_all_tasks()
code nonatomic? If you run this code in the context of the migration
thread of the downed CPU then all of the migration can be done in one big
atomic locked section which holds all runqueue locks and just moves all
tasks off the current CPU. If it were done this way then eg. the
__migrate_task() race-avoidance check (cpu_is_offline()) could go away and
the whole thing would be more robust i believe.
Ingo
next prev parent reply other threads:[~2004-02-02 9:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-31 14:16 [PATCH 3/4] 2.6.2-rc2-mm2 CPU Hotplug: The Core Rusty Russell
2004-02-01 8:03 ` Andrew Morton
2004-02-01 10:19 ` Nick Piggin
2004-02-01 12:07 ` Rusty Russell
2004-02-02 9:12 ` Ingo Molnar [this message]
2004-02-02 10:55 ` Rusty Russell
2004-02-02 12:45 ` Ingo Molnar
2004-02-02 13:22 ` Srivatsa Vaddagiri
2004-02-02 15:40 ` Ingo Molnar
2004-02-03 0:45 ` Rusty Russell
2004-02-03 8:04 ` Ingo Molnar
2004-02-03 8:16 ` Rusty Russell
2004-02-03 8:31 ` Ingo Molnar
2004-02-03 7:39 ` New v. v. experimental HOTPLUG CPU megapatch Rusty Russell
2004-02-03 9:35 ` Ingo Molnar
2004-02-05 18:12 ` Pavel Machek
2004-02-03 0:34 ` [PATCH 3/4] 2.6.2-rc2-mm2 CPU Hotplug: The Core Rusty Russell
2004-02-03 9:26 ` Ingo Molnar
2004-02-04 0:19 ` Rusty Russell
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=Pine.LNX.4.58.0402020353240.25194@devserv.devel.redhat.com \
--to=mingo@redhat.com \
--cc=akpm@osdl.org \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=piggin@cyberone.com.au \
--cc=rusty@rustcorp.com.au \
--cc=vatsa@in.ibm.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.