Possible scheduler bug

[seth bollinger]

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;
 }

I have two questions regarding this patch.

1. How was it possible to get the scheduler locked up like that (prior
to patch application)?
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)?

We're currently running kernel version 2.6.35.14 on a freescale
i.MX28. I can provide the test code that reproduces the problem (or
explanation of what it does), or a more verbose explanation of the
problem and analysis I've done if it would help.

Thanks,

Seth Bollinger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/