Ingo, I saw your patch to remove the frozen lock from the scheduler
and agree this is the best way to go. Once this change is made, I
think it is then safe to add a fast path for migration
(to set_cpus_allowed) as:
/*
* If the task is not on a runqueue (and not running), then
* it is sufficient to simply update the task's cpu field.
*/
if (!p->array && (p != rq->curr)) {
p->thread_info->cpu = __ffs(p->cpus_allowed);
task_rq_unlock(rq, &flags);
goto out;
}
Would you agree that this is now safe? My concern is not so
much with the performance of set_cpus_allowed, but rather in
using the same concept to 'move' tasks in this state.
Consider the '__wake_up_sync' functionality that existed in the
old scheduler for pipes. One result of __wake_up_sync is that
the reader and writer of the pipe were scheduled on the same
CPU. This seemed to help with pipe bandwidth. Perhaps we could
add code something like the above to wakeup a task on a specific
CPU. This could be used in VERY VERY specific cases (such as
blocking reader/writer on pipe) to increase performance.
-- Mike - 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/