Re: CPU Hotplug: Hotplug Script And SIGPWR

Rusty Russell
2004-01-21T04:38:42Z

In message <400D6A33.6020108@myrealbox.com> you write:
> (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.

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.