On Mon, 2008-02-18 at 20:49 +0530, Balbir Singh wrote: > Peter Zijlstra wrote: > > On Mon, 2008-02-18 at 20:18 +0530, Balbir Singh wrote: > > > >>> Humm, the check that should have avoided that is: > >>> > >>> /* > >>> * Are we the only task in the tree? > >>> */ > >>> if (unlikely(rq->load.weight == curr->se.load.weight)) > >>> return; > >>>
> OK, but does it belong to the cfs_rq? I'm not looking at the cfs_rq, but at rq. Looking at cfs_rq isn't correct because it might be a group with only a single task even though there might be more tasks on this cpu. Now it turns out, looking at the rq isn't correct either. At the time I think I thought that a runnable RT task would've preempted - but that is of course not valid under all preemption models - and racy even on PREEMPT=y > >> Having said that, rightmost was indeed > >> NULL, so I need to figure out why it was. The other question is why would > >> a real > >> time task be found by sched_yield_fair? > > > > Because a rt task contributes weight and would make the test above fail > > because rt->load would be larger than expected. > > > > I thought we were searching an RBtree for the fair group scheduler. If what > you > say is indeed true, shouldn't we check if the task is an rt task in > sched_yield_fair() instead of the !rightmost check? We're not actually finding a rt task. Just the presence of a runnable RT task on this CPU skews the weights and fools my test. rightmost returns NULL because there just isn't anybody else in the CFS rq (note that current isn't in the tree). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
