Re: Scheduler questions
From: William Lee Irwin III (wli_at_holomorphy.com)
Date: 06/16/04
- Previous message: Jörn Engel: "Re: [PATCH] [STACK] >3k call path in ide"
- In reply to: Zoltan Menyhart: "Scheduler questions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 16 Jun 2004 02:54:59 -0700 To: Zoltan Menyhart <Zoltan.Menyhart_AT_bull.net@nospam.org>
On Fri, Jun 04, 2004 at 05:10:22PM +0200, Zoltan Menyhart wrote:
> I'd like to understand which task structure elements are protected by
> which locks (as far as scheduling is concerned). Is there somewhere a
> paper summarizing the mutual exclusion rules ?
> Let's take some code e.g. from the 2.6.5 kernel:
> set_cpus_allowed(task_t *p, cpumask_t new_mask):
>
> rq = task_rq_lock(p, &flags)
> __set_cpus_allowed(p, new_mask, &req):
>
> p->cpus_allowed = new_mask
> /*
> * 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 && !task_running(rq, p))
> set_task_cpu(p, any_online_cpu(p->cpus_allowed))
> /* ... */
>
> task_rq_unlock(rq, &flags)
Okay.
On Fri, Jun 04, 2004 at 05:10:22PM +0200, Zoltan Menyhart wrote:
> Apparently, the "p->cpus_allowed" and the "p->thread_info->cpu" fields
> are protected by the "(&per_cpu(runqueues, (p->thread_info->cpu)))->lock".
> Which are the other task structure elements protected by the same lock ?
> Let's take an example:
Yes. ->cpus_allowed is protected by rq->lock. Do not look at the midget
behind the curtain for what protects ->cpus_allowed of a sleeping task.
On Fri, Jun 04, 2004 at 05:10:22PM +0200, Zoltan Menyhart wrote:
> - I've got a sleeping task that ran on the CPU #3 previously
> - I want to set its CPU mask equal to {1, 2}
> - I take the lock of the run queue #3
> - I do set the CPU mask of the task
> - It's not running (BTW when can happen that "p->array" is NULL and the
> task is still running ?)
> - I do set the task's CPU e.g. equal to 2. As a consequence, the task
> falls out of the protection provided by the lock of the run queue #3.
> - Someone else deciding to play with the same task, s/he takes the
> lock of the run queue #2 !!!
> - Me, I have not arrived yet to the unlock. There are stuffs to do before.
> - Both of us think to have the exclusive access right to the task...
> Can someone explain me, please, why I have to take a run queue lock
> to protect a not running task, and why we do not use "proc_lock"
> instead ?
You looked at the midget behind the curtain. Anyway, rq->lock is just
reused based on the sleeping task's cpu affinity.
->array == NULL while a task is running should not happen apart from
a dequeueing in progress. ->array should be protected by
per_cpu(runqueues, task_cpu(task)).lock.
Scheduler-private fields of tasks are considered to be under the
protection of per_cpu(runqueues, task_cpu(task)).lock until someone
succeeds in a double runqueue lock acquisition and moves the task
between two cpus, or as an optimization, to reset task->thread_info->cpu
under its current rq->lock without holding the target's lock if it's not
queued anywhere.
There is some retry logic in task_rq_lock() to make sure the cpu and
the runqueue are consistent that resolves the remainder of the cases.
-- wli
-
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/
- Previous message: Jörn Engel: "Re: [PATCH] [STACK] >3k call path in ide"
- In reply to: Zoltan Menyhart: "Scheduler questions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
