set_cpus_allowed() optimization

[Mike Kravetz]

Please consider the following optimization to set_cpus_allowed().
In the case where the task does not reside on a runqueue, is it
not safe/sufficient to simply set the task's cpu field?  This
would avoid scheduling the migration thread to perform the task.

Previously, set_cpus_allowed() was always called for a task that
resides on a runqueue.  With the introduction of the 'cpu affinity'
system calls, this is no longer the case.

Does this seem reasonable?

A patch for 2.5.15 is included below.

-- 
Mike

diff -Naur linux-2.5.15/kernel/sched.c linux-2.5.15-sca/kernel/sched.c
--- linux-2.5.15/kernel/sched.c	Thu May  9 22:22:53 2002
+++ linux-2.5.15-sca/kernel/sched.c	Fri May 10 19:51:58 2002
@@ -1670,13 +1670,22 @@
 	rq = task_rq_lock(p, &flags);
 	p->cpus_allowed = new_mask;
 	/*
-	 * Can the task run on the task's current CPU? If not then
-	 * migrate the process off to a proper CPU.
+	 * Can the task run on the task's current CPU?
+	 * If yes, we are done.
 	 */
 	if (new_mask & (1UL << p->thread_info->cpu)) {
 		task_rq_unlock(rq, &flags);
 		goto out;
 	}
+	/*
+	 * If the task is not on a runqueue, then it is safe to
+	 * simply update the task's cpu field.
+	 */
+	if (!p->array) {
+		p->thread_info->cpu = __ffs(p->cpus_allowed);
+		task_rq_unlock(rq, &flags);
+		goto out;
+	}
 
 	init_MUTEX_LOCKED(&req.sem);
 	req.task = p;