On Tue, 23 Apr 2002, Mike Kravetz wrote:
> I don't have a suggestion for the locking yet, but rather a question
> about the current code that you may be able to answer. At the end of
> set_cpus_allowed(), there is this block of code:
>
> init_MUTEX_LOCKED(&req.sem);
> req.task = p;
> list_add(&req.list, &rq->migration_queue);
> task_rq_unlock(rq, &flags);
> wake_up_process(rq->migration_thread);
>
> down(&req.sem);
>
> After releasing the runqueue lock, what prevents p from moving to (and
> running on) another CPU via the load_balance() mechanism before the
> migration thread is scheduled? I couldn't find anything in the code to
> prevent this, and it looks like bad things would happen if it did. Of
> course, this assumes we are not running in the context of p while
> calling set_cpus_allowed() for p.
well, my goal was the following: the migration thread makes sure that the
migrated thread will *not* run on that particular CPU. The only issue the
migration thread is for is to 'push' the migrated thread from its current
CPU.
so we first set the cpus_allowed mask, then we schedule the migration
thread (which is a highest RT priority thread) if the thread is running on
an invalid CPU.
load_balance() moving a process to another CPU is in fact makes this job
easier, and causes no problems. It will pull a process only to allowed
runqueues.
this way it can be guaranteed that after the set_cpus_allowed() call the
thread is not running on an invalid CPU.
the affinity setting syscalls added by Robert's patch utilize this
underlying mechanizm, but kernel threads call it directly as well. Eg. in
the softirqd case it's of importance whether the thread is running on the
right CPU or not, after calling set_cpus_allowed().
is there anything else unclear in this area?
Ingo
-
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 Apr 23 2002 - 22:00:35 EST