On 28/07/07, Chris Snook <[EMAIL PROTECTED]> wrote: > [ ... ] > Under CFS, the yielding process will still be leftmost in the rbtree, > otherwise it would have already been scheduled out.
Not actually true. The position of the 'current' task within the rb-tree is updated with a timer tick's frequency. Being called somewhere in between 2 ticks, sched_yield() may trigger a reschedule which would otherwise take place upon the next tick. Moreover, 'scheduling granularity' may also take effect. e.g. effectively, the yielding task's 'fair_key' was already != 'left_most' upon the previous timer tick but an actual reschedule has been delayed due to the 'scheduling granularity' taking effect... and sched_yield() may trigger it. > Zeroing out wait_runtime on sched_yield strikes me as completely appropriate. > If the process wanted to sleep a finite duration, it should actually call a > sleep function, but sched_yield is essentially saying "I don't have anything > else to do right now", so it's hardly fair to claim you've been waiting for > your > chance when you just gave it up. 'wait_runtime' describes dynamic behavior of a task on the rq. It doesn't matter what the task is about to do as 'wait_runtime' is something it fully deserves. Note, 'wait_runtime' can be both positive and negative, meaning credit/punishment appropriately. When it's negative, 'zeroing it out' effectively means the task gets helped -- in the sense that it doen't get 'punished' for some amount of time it actually spent running. Which is wrong. One more thing: we don't take time accounted to 'wait_runtime' just from the thin air. e.g. sleepers get an additional bonus to their 'wait_runtime' upon a wakeup _but_ the amount of "wait_runtime" == "a given bonus" will be additionally substracted from tasks which happen to run later on (grep for "sleeper_bonus" in sched_fair.c). That said, the sum (of additionally given/taken wait_runtime) is zero. All in all, I doubt the "zeroing out wait_runtime on sched_yield" thing is really appropriate. > > -- Chris > -- Best regards, Dmitry Adamushko - 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/
