Re: CPU Hotplug: Hotplug Script And SIGPWR

[Tim Hockin <thockin@hockin.org>]

On Tue, Jan 20, 2004 at 06:45:41PM +1100, Rusty Russell wrote:
> In message <20040120063316.GA9736@hockin.org> you write:
> > I added a new TASK_UNRUNNABLE state for these tasks, too.  By adding the
> > task's current (or most recent) CPU and the task's cpus_allowed and
> > cpus_allowed_mask to /proc/pid/status, we gave simple tools for finding
> > these unrunnable tasks.
> > 
> > I think the sanest thing for a CPU removal is to migrate everything off the
> > processor in question, move unrunnable tasks into TASK_UNRUNNABLE state,
> > then notify /sbin/hotplug.  The hotplug script can then find and handle the
> > unrunnable tasks.  No SIGPWR grossness needed.
> 
> Interesting.
> 
> The downside is that you now need some script needs to know what to do
> with the tasks (unless you have something like DBUS, but that's a ways

Well, if we provide a sane example script, the rest is up to the distros or
the people with this hardware to decide.

> off).  There are no correctness concerns AFAICT with userspace not
> being on a particular CPU, just performance.

Correctness does matter if an affined task violates that affinity.  If we
are going to provide explicit affinity, we need to honor it under all
conditions, or at least provide an option to honor it.

> The SIGPWR solution lets a random process deal appropriately without
> having to interface with /sbin/hotplug, if it wants to.  And it's a
> lot less invasive.

I agree about invasiveness.  Maybe a combo?  Send SIGPWR iff a task is
actually handling it, otherwise mark it TASK_UNRUNNABLE and let hotplug
handle it?  A new signal would be much more polite, but SIGPWR can be made
to work.  What if a process catches SIGPWR, but does not handle CPU removal?
Do we wait for it's signal handler to finish before re-evaluating it for
TASK_UNRUNNABLE?  Yuck.  If a CPU gets yanked with no warning, where do we
run the signal handler?  Violating affinity again.

Tim