All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	akpm@osdl.org, linux-kernel@vger.kernel.org,
	Nick Piggin <piggin@cyberone.com.au>,
	dipankar@in.ibm.com
Subject: Re: [PATCH 3/4] 2.6.2-rc2-mm2 CPU Hotplug: The Core
Date: Mon, 2 Feb 2004 16:40:40 +0100	[thread overview]
Message-ID: <20040202154040.GA5895@elte.hu> (raw)
In-Reply-To: <20040202132230.GA21772@in.ibm.com>


* Srivatsa Vaddagiri <vatsa@in.ibm.com> wrote:

> One possibility is the migration request will be in CPU 0's queue and
> not in CPU1's? Hence there won't be anything (in CPU1's migration
> request queue) to process when CPU1 is brought down. However by the
> time migration thread on CPU 0 gets around to processing the request,
> CPU1 is already down and hence the check.

IMO the semantics of this area are not defined clearly enough, hence
these problems. __migrate_task(cpu) is a wrapper around
set_cpus_allowed(). If a CPU goes away atomically then the only source
of some non-online CPU is from user-space or unsafe references of
smp_processor_id() [which are also preempt-unsafe so need to be fixed
anyway]. set_cpus_allowed() deals with invalid masks just fine: it does
nothing and returns an error. The following sequence shouldnt be
possible to trigger if CPU-down is an atomic event:

        /* Affinity changed (again). */
        if (!cpu_isset(dest_cpu, p->cpus_allowed))
                goto out;
        /* CPU went down. */
        if (cpu_is_offline(dest_cpu))
                goto out;

because p->cpus_allowed is fixed up atomically. If this task is in
CPU1's migration queue then the CPU-down mechanism takes care of it. If
this task is in CPU0's migration queue then the task will be migrated
off CPU1 by the CPU-down mechanism and CPU0's migration wont have alot
of work left.

kernel-space threads that rely on running on a specific CPU need the
callback mechanism on CPU-down, so there's no problem with them.

user-space tasks that rely on running on a specific CPU need a callback
too. (probably in the form of a signal, which, if unhandled, terminates
the task.) Eg. if a webserver has a mode to run one thread per CPU, then
the server needs to adapt to the new situation when a CPU goes away. We
cannot just unilaterally migrate a task and violate its affinity.

another thing: if the migrate-irqs op is done atomically too (together
with the migrate-tasks op) then the special-cases in idle_balance() and
rebalance_tick() could go away too.

	Ingo

  reply	other threads:[~2004-02-02 15:43 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
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 [this message]
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=20040202154040.GA5895@elte.hu \
    --to=mingo@elte.hu \
    --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.