question about blk_schedule_flush_plug
I was looking at the scheduler changes going into 2.6.39 again and wondered about the use of blk_schedule_flush_plug smack in the middle of schedule()
It looks like this:
if (blk_needs_flush_plug(prev)) {
raw_spin_unlock(&rq->lock);
blk_schedule_flush_plug(prev);
raw_spin_lock(&rq->lock);
}Now call me suspicious but to my eyes it looks really dubious unlocking the runqueue like that right in the heart of schedule().
Comments?
Thanks,
Con
Signature · 1 line
-ck
Quoted 10 lines · Con Kolivas
I was looking at the scheduler changes going into 2.6.39 again and wondered about the use of
blk_schedule_flush_plugsmack in the middle ofschedule()It looks like this:
if (blk_needs_flush_plug(prev)) { raw_spin_unlock(&rq->lock); blk_schedule_flush_plug(prev); raw_spin_lock(&rq->lock); }
Quoted 4 lines
Now call me suspicious but to my eyes it looks really dubious unlocking the runqueue like that right in the heart of
schedule().Comments?
Yeah, that's quite all-right, both pre_schedule() and idle_balance() already did that too.
We can safely release the runqueue lock after deactivate_task() and before put_prev_task().
Quoted 10 lines · Con Kolivas
I was looking at the scheduler changes going into 2.6.39 again and wondered about the use of
blk_schedule_flush_plugsmack in the middle ofschedule()It looks like this:
if (blk_needs_flush_plug(prev)) { raw_spin_unlock(&rq->lock); blk_schedule_flush_plug(prev); raw_spin_lock(&rq->lock); }
Quoted 4 lines
Now call me suspicious but to my eyes it looks really dubious unlocking the runqueue like that right in the heart of
schedule().Comments?
Releasing/retaking rq->lock is nothing new:
static void idle_balance(int this_cpu, struct rq *this_rq) {
...
/*
* Drop the rq->lock, but keep IRQ/preempt disabled.
*/
raw_spin_unlock(&this_rq->lock);See also need_resched, and double_lock_balance() instances.
-Mike