[lkml]   [2011]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Possible scheduler bug
On Tue, 2011-08-23 at 20:58 -0500, seth bollinger wrote:
> Hello All,
> We recently ran into an interesting scheduler problem when testing one
> of our products. It manifested itself as a user space lockup. When I
> enabled/printed scheduler stats I noticed that the scheduler was
> always picking the same task to run, and no task stats were being
> updated(clock, sum_exec, sum_sleep, etc.). The scheduler would become
> stuck in this state permanently. This problem was ultimately resolved
> by the following patch to sched.c
> @@ -564,7 +569,7 @@ void check_preempt_curr(struct rq *rq, struct
> task_struct *p, int flags)
> * A queue event has occurred, and we're going to schedule. In
> * this case, we can save a useless back to back clock update.
> */
> - if (test_tsk_need_resched(p))
> + if (rq->curr->se.on_rq && test_tsk_need_resched(rq->curr))
> rq->skip_clock_update = 1;
> }

Yeah, that's correct, but see f26f9aff6aaf67e9a430d16c266f91b13a5bff64.
You'll also want the other bits as well. (but not the WARN_ON())

> I have two questions regarding this patch.
> 1. How was it possible to get the scheduler locked up like that (prior
> to patch application)?

If the clock isn't updated, vruntimes don't advance, so you could end up
selecting the same task repeatedly.

> 2. After patch, is it possible that the scheduler could spin in this
> loop until a sched_clock() tick (our clock resolution is unfortunately
> 10ms)?

If you take the rest of the fix, that shouldn't happen.


 \ /
  Last update: 2011-08-24 05:45    [W:0.034 / U:0.088 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site