Re: CPU Hotplug: Hotplug Script And SIGPWR

[Nick Piggin]

Tim Hockin wrote:

> 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).


Seems less robust and more ad hoc than SIGPWR, however.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/