![]() | |||||||||||
Messages in this thread |
On Wed, 21 Jun 2006, Andrew Morton wrote: > > Now, when a task loses all of its allowed cpus because of cpu hot removal, > > it will be foreced to migrate to not-allowed cpus. > > > > In this case, the task is not properly reconfigurated by a user before > > cpu-hot-removal. Here, the task (and system) is in a unexpeced wrong state. > > This migration is maybe one of realistic workarounds. But sometimes it will be > > harmfull. > > (stealing other cpu time, making bugs in thread controllers, do some unexpected > > execution...) > > > > This patch adds sysctl "sigstop_on_cpu_lost". When sigstop_on_cpu_lost==1, > > a task which losts is cpu will be stopped by SIGSTOP. > > Depends on system management policy, mis-configurated applications are stopped. > > > > Well that's a pretty unpleasant patch, isn't it? The cleanest solution is to terminate the process. If the user has configured the process to only run on a certain cpu and the processor then becomes unavailable then the process needs to terminate by default since it has no resource left to run. This is similar to an Out of Memory condition. We can add this sigstop_on_cpu_lost as an additional measure but it should be off by default. So far we have never had the system stop a process because resources are not available. This would be unexpected system behavior. - 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/ | ||||||||||
| Last update: 2006-06-22 08:17 [from the cache] ©2003-2008 | |||||||||||