Messages in this thread | | | Date | Tue, 20 Jan 2004 01:12:20 -0800 | From | Tim Hockin <> | Subject | Re: CPU Hotplug: Hotplug Script And SIGPWR |
| |
On Tue, Jan 20, 2004 at 07:49:45PM +1100, Nick Piggin wrote: > Well I'll admit it would usually be more flexible if you freeze > the process and run hotplug scripts to handle cpu affinity. > > Unfortunately it introduces unfixable robustness and realtime > problems by design.
And I submit that there is no clean way to handle the RT problem. The proposed flag gives the task a choice, which is good, but I am not sure that the choice is worth the effort.
The robustness issues are real, but the same issue applies to all hotplug activity. The issues are severe corner cases which indicate OTHER faults in the system.
My main concern is that affinity is not treated as a suggestion or preference. Affinity is an explicit request. Once granted, we can not arbitrarily decide to revoke affinity unless we have a sane way to alert *someone*.
Freezing tasks and sending a hotplug event is a sane way.
Sending SIGPWR is a sane way IFF you can guarantee that a task which receives SIGPWR will handle a CPU being yanked without violating affinity. This does not handle the case of tasks which do not handle SIGPWR.
A flag to indicate 'my affinity is a preference' vs. 'my affinity is a requirement' is a possibly sane way. It still requires all the code to freeze a task, and forces affinity-aware apps to adapt to this new edge case. - 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/
| |