aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
diff options
context:
space:
mode:
authorMike Galbraith <efault@gmx.de>2010-12-06 00:33:27 -0500
committerBjoern B. Brandenburg <bbb@cs.unc.edu>2010-12-06 09:26:59 -0500
commitee0e01a2e4d3b9266ca44a83271b22aa59b289f3 (patch)
tree0c1789f277863a1345580123e65a46e2869c6089 /drivers
parent771f8bc71c31c6bd103cdec283012253f352ab1c (diff)
Scheduler bug related to rq->skip_clock_update?
On Sun, 2010-12-05 at 13:28 +0800, Yong Zhang wrote: > when we init idle task, we doesn't mark it on_rq. > My test show the concern is smoothed by below patch. Close :) The skip_clock_update flag should only be set if rq->curr is on_rq, because it it _that_ clock update during dequeue, and subsequent microscopic vruntime update it causes that we're trying to avoid. I think the below fixes it up properly. Sched: fix skip_clock_update optimization idle_balance() drops/retakes rq->lock, leaving the previous task vulnerable to set_tsk_need_resched(). Clear it after we return from balancing instead, and in setup_thread_stack() as well, so no successfully descheduled or never scheduled task has it set. Need resched confused the skip_clock_update logic, which assumes that the next call to update_rq_clock() will come nearly immediately after being set. Make the optimization robust against the waking a sleeper before it sucessfully deschedules case by checking that the current task has not been dequeued before setting the flag, since it is that useless clock update we're trying to save, and clear in update_rq_clock() to ensure that ONE call may be skipped. Signed-off-by: Mike Galbraith <efault@gmx.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Bjoern B. Brandenburg <bbb.lst@gmail.com> Reported-by: Bjoern B. Brandenburg <bbb.lst@gmail.com>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions