From: Tim Hockin <thockin@hockin.org>
To: Srivatsa Vaddagiri <vatsa@in.ibm.com>
Cc: Nick Piggin <piggin@cyberone.com.au>,
Rusty Russell <rusty@au1.ibm.com>,
linux-kernel@vger.kernel.org, torvalds@osdl.org, akpm@osdl.org,
rml@tech9.net
Subject: Re: CPU Hotplug: Hotplug Script And SIGPWR
Date: Tue, 20 Jan 2004 23:08:44 -0800 [thread overview]
Message-ID: <20040121070844.GA31807@hockin.org> (raw)
In-Reply-To: <20040121103933.B3236@in.ibm.com>
On Wed, Jan 21, 2004 at 10:39:33AM +0530, Srivatsa Vaddagiri wrote:
> > *Before* that happens, tasks that don't handle the signal should just
> > have their affinity changed to all cpus.
>
> Currently, handle or not handle the signal, affinity is changed
> to all cpus for tasks that are bound only to the dying CPU.
OK, so lets assume this scenarion:
process A affined to cpu1
all other processes affined to 0xffffffff
cpu1 goes down
- process A affined to 0xffffffff
hotplug "cpu1 removed" event
cpu1 comes back
hotplug "cpu1 inserted" event
Process A has now discarded useful potentially VALUABLE information, with no
way to retrieve it. The hot plug scripts do not have enough information to
put things the way they were before. I can't believe that anyone considers
this to be OK.
Userspace gave us EXPLICIT instructions, which we then violate. By granting
affinity, we have made a contract with userspace. Changing affinity without
userspace's direct instruction is wrong.
What about this:
We already can not handle unexpected CPU removals gracefully, correct? So
we expect some user-provided notification, right?
So force userland to handle it before we give the OK to remove a CPU.
pid_t sys_proc_offline(int cpu)
{
pid_t p;
/* flag cpu as not schedulale anymore */
dont_add_tasks_to(cpu);
p = find_first_unrunnable(cpu);
if (p)
return p;
take_proc_offline(cpu);
return 0;
}
The userspace control can then loop on this until it returns 0. Each time
it return a pid, userspace must try to handle that pid - kill it,
re-affine it, or provide some way to suspend it.
Simpler yet:
int sys_proc_offline(int cpu, int reaffine)
{
pid_t p;
/* flag cpu as not schedulale anymore */
dont_add_tasks_to(cpu);
while ((p = find_first_unrunnable(cpu))) {
if (reaffine)
reaffine(p);
else
make_unrunnable(p);
}
take_proc_offline(cpu);
return 0;
}
Less flexible, but workable. I prefer the first. Yes it's racy, but the
worst case is that you receive a pid that you don't need to handle (died or
re-affined already).
Anything that violates affinity without permission just is so WRONG.
next prev parent reply other threads:[~2004-01-21 7:08 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040116174446.A2820@in.ibm.com>
2004-01-20 5:44 ` CPU Hotplug: Hotplug Script And SIGPWR Rusty Russell
2004-01-20 6:33 ` Tim Hockin
2004-01-20 6:43 ` Nick Piggin
2004-01-20 6:52 ` Tim Hockin
2004-01-20 7:11 ` Nick Piggin
2004-01-20 7:30 ` Tim Hockin
2004-01-20 7:45 ` Nick Piggin
2004-01-20 7:54 ` Tim Hockin
2004-01-20 8:14 ` Nick Piggin
2004-01-20 8:29 ` Tim Hockin
2004-01-20 8:37 ` Nick Piggin
2004-01-20 8:43 ` Tim Hockin
2004-01-21 4:06 ` Srivatsa Vaddagiri
2004-01-21 4:14 ` Nick Piggin
2004-01-21 5:09 ` Srivatsa Vaddagiri
2004-01-21 7:08 ` Tim Hockin [this message]
2004-01-21 15:07 ` Matthias Urlichs
2004-01-22 5:29 ` Rusty Russell
2004-01-21 7:09 ` Tim Hockin
2004-01-21 7:31 ` Nick Piggin
2004-01-21 7:42 ` Tim Hockin
2004-01-21 8:11 ` Rusty Russell
2004-01-21 5:07 ` Rusty Russell
2004-01-20 8:41 ` Stefan Smietanowski
2004-01-20 8:49 ` Nick Piggin
2004-01-20 9:12 ` Tim Hockin
2004-01-21 0:00 ` Rusty Russell
2004-01-20 23:51 ` Rusty Russell
2004-01-20 7:45 ` Rusty Russell
2004-01-20 8:37 ` Tim Hockin
2004-01-20 9:29 ` Srivatsa Vaddagiri
2004-01-21 0:12 ` Rusty Russell
[not found] <fa.f37o48p.1io5q5@ifi.uio.no>
[not found] ` <fa.frjqvfo.170g8hq@ifi.uio.no>
2004-01-20 17:49 ` Andy Lutomirski
2004-01-21 4:33 ` 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=20040121070844.GA31807@hockin.org \
--to=thockin@hockin.org \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=piggin@cyberone.com.au \
--cc=rml@tech9.net \
--cc=rusty@au1.ibm.com \
--cc=torvalds@osdl.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox