Re: CPU Hotplug: Hotplug Script And SIGPWR

[Tim Hockin]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/