CPU Hotplug: Hotplug Script And SIGPWR
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Tim Hockin
Quoted 6 lines · Nick Piggin
Quoted 5 lines
I think the sanest thing for a CPU removal is to migrate everything off the processor in question, move unrunnable tasks into
TASK_UNRUNNABLEstate, then notify/sbin/hotplug. The hotplug script can then find and handle the unrunnable tasks. No SIGPWR grossness needed.
Quoted 7 lines
Quoted 1 line
Seems less robust and more ad hoc than SIGPWR, however.
Disagree. SIGPWR will kill any process that doesn't catch it. That's policy. It seems more robust to let the hotplug script decide what to do. If it wants to kill each unrunnable task with SIGPWR, it can. But if it wants to let them live, it can.
This seems like a problem that a lot of power-management issues have. (At some point, linux may want to suspend itself after inactivity. Both RT tasks and some interactive tasks may want to supress that.) Why not add a SIGPM signal, which is only sent if handles, and which indicates that PM event is happening. Give usermode some method of responding to it (e.g. handler returns a value, or a new syscall), and let /sbin/hotplug handle events for tasks that either ignore the signal or responded that they were uninterested. This seems be close to optimal for every case I can think of.
--Andy
In message <[email protected]> you write:
Quoted 8 lines
(At some point, linux may want to suspend itself after inactivity. Both RT tasks and some interactive tasks may want to supress that.) Why not add a SIGPM signal, which is only sent if handles, and which indicates that PM event is happening. Give usermode some method of responding to it (e.g. handler returns a value, or a new syscall), and let
/sbin/hotplughandle events for tasks that either ignore the signal or responded that they were uninterested. This seems be close to optimal for every case I can think of.
This was my original idea too. AIX has this, but in reality the control ends up all in userspace for non-trivial uses. ie. some "workload manager" program consults with all the interested parties *before* telling the kernel what to do.
The async and non-consultive nature of hotplug is policy for good reason. Giving someone 30 seconds to respond to a signal can always fail, and making it configurable is just a bandaid.
I have nothing against SIGRECONFIG (think memory hotplug), but the AIX guys indicated from their experience it seems that non-toy users don't use it anyway (they have a hotplug-style script system, too).
So: trying to cover every corner case isn't worthwhile in practice, it seems. I like the signal for RC5 challenge etc, but that's about it.
Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.