[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.022 / U:6.748 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site