Re: CPU Hotplug: Hotplug Script And SIGPWR

Tim Hockin
2004-01-20T06:33:40Z

On Tue, Jan 20, 2004 at 04:44:45PM +1100, Rusty Russell wrote:
> The other issue I wanted to revisit: we currently send SIGPWR to all
> processes which we have to undo the CPU affinity for (with a new
> si_info field containing the cpu going down).
>
> The main problem is that a process can call sched_setaffinity on
> another (unrelated) task, which might not know about it. One option
> would be to only deliver the signal if it's not SIG_DFL for that
> process. Another would be not to signal, and expect hotplug scripts
> to clean up.

I had to deal with this in my procstate patch (was against RH 2.4 with O(1)
sched but not 2.6). What I chose to do (and what the people who were
wanting the code wanted) was to move tasks which had no CPU to run upon onto
an unrunnable list. Whenever a CPU's state is changed, scan the list.
Whenevr a task's affinity mask is changed, check if it needs to go onto or
come off of the unrunnable_list.

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.

Code against 2.4 at http://www.hockin.org/~thockin/procstate - it was
heavily tested and I *think* it is all correct (for that kernel snapshot).

Tim