Messages in this thread | | | Date | Tue, 20 Jan 2004 19:37:48 +1100 | From | Nick Piggin <> | Subject | Re: CPU Hotplug: Hotplug Script And SIGPWR |
| |
Tim Hockin wrote:
>On Tue, Jan 20, 2004 at 07:14:12PM +1100, Nick Piggin wrote: > >>>Under what conditions? Not arbitrary entropy, surely. If a hotplug script >>>is present and does not blow up, it should be safe to assume it will be run >>>upon an event being delivered. If not, we have a WAY bigger problem :) >>> >>> >>That assumption is not safe. The main problems are of course process limits >>and memory allocation failure. >> > >If root has a process limit that make hotplug scripts fail to run, then >we're hosed in a lot of ways. And if we fail to allocate memory, there >really ought to be some retry or something. It seems to me that a failure >to run a hotplug script is a BAD THING. >
(or OOM killed being another that comes to mind)
It is sometimes inevitable. With that knowledge we should be designing for graceful failure.
> >>>Sending it a SIGPWR means you have to run it on a different CPU that it was >>>affined to, which is already a violation. >>> >>At least the task has the option to handle the problem. >> > >But it is a violation of the affinity. As the kernel we CAN NOT know what >the affinity really means. >
Not if the application is designed to handle it. How would hotplug scripts make this any different, anyway?
> Maybe there is some way for a task to indicate >it would like to receive SIGPWR in that case. Or some other signal. Can we >invent new signals? > >That way a task that KNOWS about the CPU disappearing underneath it can be >wise, while everything else will not just get killed. >
Rusty thought you just wouldn't send it unless the process was handling it.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |