When reattaching a task to a different cpuset, I hadcode that attempted to preserve the cpuset relativeplacement of the task (such as might have been doneusing sched_setaffinity, mbind or set_mempolicy) byrebinding the task to the intersection of its oldand new placement, if not empty.

This resulted in strange and puzzling behaviour, suchas having a tasks cpus_allowed not change if the taskwas 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.

- /*- * 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))-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.650.933.1373-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at http://www.tux.org/lkml/