From: Paul Jackson When reattaching a task to a different cpuset, I had code that attempted to preserve the cpuset relative placement of the task (such as might have been done using sched_setaffinity, mbind or set_mempolicy) by rebinding the task to the intersection of its old and new placement, if not empty. This resulted in strange and puzzling behaviour, such as having a tasks cpus_allowed not change if the task was reattached to the root cpuset. Simplify the code - when attaching a task to a cpuset, simply set its cpus_allowed to that of the cpuset. This is much less surprising in practice. Signed-off-by: Paul Jackson Signed-off-by: Andrew Morton --- 25-akpm/kernel/cpuset.c | 12 +----------- 1 files changed, 1 insertion(+), 11 deletions(-) diff -puN kernel/cpuset.c~cpusets-simplify-cpus_allowed-setting-in-attach kernel/cpuset.c --- 25/kernel/cpuset.c~cpusets-simplify-cpus_allowed-setting-in-attach 2004-09-11 17:26:04.867894664 -0700 +++ 25-akpm/kernel/cpuset.c 2004-09-11 17:26:04.872893904 -0700 @@ -610,7 +610,6 @@ static int attach_task(struct cpuset *cs pid_t pid; struct task_struct *tsk; struct cpuset *oldcs; - cpumask_t cpus; if (sscanf(buf, "%d", &pid) != 1) return -EIO; @@ -650,16 +649,7 @@ static int attach_task(struct cpuset *cs tsk->cpuset = cs; task_unlock(tsk); - /* - * If the tasks current CPU placement overlaps with its new cpuset, - * then let it run in that overlap. Otherwise fallback to simply - * letting it have the run of the CPUs in the new cpuset. - */ - if (cpus_intersects(tsk->cpus_allowed, cs->cpus_allowed)) - cpus_and(cpus, tsk->cpus_allowed, cs->cpus_allowed); - else - cpus = cs->cpus_allowed; - set_cpus_allowed(tsk, cpus); + set_cpus_allowed(tsk, cs->cpus_allowed); put_task_struct(tsk); if (atomic_dec_and_test(&oldcs->count)) _