CFS rq lock question

CFS rq lock question

[Dan Upton]

I'm poking around with some scheduler stuff, and there's something I'm
not clear on for the CFS runqueue locks.  The comments before
__load_balance_iterator(...) in sched_fair.c suggests things can be
dequeued even though the runqueue lock is held.  Can things also be
added to the queue while the lock is held?  (Also, either way, what's
the rationale that dequeueing is a safe procedure when somebody else
holds a lock?)

-dan

Re: CFS rq lock question

[Peter Zijlstra]

On Fri, 2008-04-11 at 13:21 -0400, Dan Upton wrote:
> I'm poking around with some scheduler stuff, and there's something I'm
> not clear on for the CFS runqueue locks.  The comments before
> __load_balance_iterator(...) in sched_fair.c suggests things can be
> dequeued even though the runqueue lock is held.  Can things also be
> added to the queue while the lock is held?  (Also, either way, what's
> the rationale that dequeueing is a safe procedure when somebody else
> holds a lock?)

/*
 * Load-balancing iterator. Note: while the runqueue stays locked
 * during the whole iteration, the current task might be
 * dequeued so the iterator has to be dequeue-safe. Here we
 * achieve that by always pre-iterating before returning
 * the current task:
 */

I don't think this comment is correct, but if it were, it would only
apply to rq->curr, not for any enqueue/dequeue.

Re: CFS rq lock question

[Peter Zijlstra]

On Fri, 2008-04-11 at 19:37 +0200, Peter Zijlstra wrote:
> On Fri, 2008-04-11 at 13:21 -0400, Dan Upton wrote:
> > I'm poking around with some scheduler stuff, and there's something I'm
> > not clear on for the CFS runqueue locks.  The comments before
> > __load_balance_iterator(...) in sched_fair.c suggests things can be
> > dequeued even though the runqueue lock is held.  Can things also be
> > added to the queue while the lock is held?  (Also, either way, what's
> > the rationale that dequeueing is a safe procedure when somebody else
> > holds a lock?)
> 
> /*
>  * Load-balancing iterator. Note: while the runqueue stays locked
>  * during the whole iteration, the current task might be
>  * dequeued so the iterator has to be dequeue-safe. Here we
>  * achieve that by always pre-iterating before returning
>  * the current task:
>  */
> 
> I don't think this comment is correct, but if it were, it would only
> apply to rq->curr, not for any enqueue/dequeue.
> 

D'oh, I'm silly..

the task can be dequeued because we move it to another cpu.