Messages in this thread | | | Date | Wed, 17 Nov 2004 09:19:53 +1100 | From | Peter Williams <> | Subject | Re: [patch, 2.6.10-rc2] sched: fix ->nr_uninterruptible handling bugs |
| |
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@bigpond.net.au
"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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |