Re: [patch, 2.6.10-rc2] sched: fix ->nr_uninterruptible handlingbugs

[Peter Williams]

Ingo Molnar wrote:
> PREEMPT_RT on SMP systems triggered weird (very high) load average
> values rather easily, which turned out to be a mainline kernel
> ->nr_uninterruptible handling bug in try_to_wake_up().
>
> the following code:
>
>         if (old_state == TASK_UNINTERRUPTIBLE) {
>                 old_rq->nr_uninterruptible--;
>
> potentially executes with old_rq potentially being != rq, and hence
> updating ->nr_uninterruptible without the lock held. Given a
> sufficiently concurrent preemption workload the count can get out of
> whack and updates might get lost, permanently skewing the global count. 
> Nothing except the load-average uses nr_uninterruptible() so this
> condition can go unnoticed quite easily.
>
> the fix is to update ->nr_uninterruptible always on the runqueue where
> the task currently is. (this is also a tiny performance plus for
> try_to_wake_up() as a stackslot gets freed up.)

Couldn't this part of the problem have been solved by using an atomic_t 
for nr_uninterruptible as for nr_iowait?  It would also remove the need 
for migrate_nr_uninterruptible().

Peter
--
Peter Williams                                   pwil3058@xxxxxxxxxxxxxx

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
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/