set_cpus_allowed() optimization

From: Mike Kravetz (kravetz@us.ibm.com)
Date: Fri May 10 2002 - 15:09:04 EST


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; - 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/



This archive was generated by hypermail 2b29 : Tue May 14 2002 - 12:00:14 EST