Messages in this thread | | | Date | Wed, 17 Nov 2004 10:48:38 +1100 | From | Peter Williams <> | Subject | Re: [patch, 2.6.10-rc2] sched: fix ->nr_uninterruptible handling bugs |
| |
Ingo Molnar wrote: > * Peter Williams <pwil3058@bigpond.net.au> wrote: > > >>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(). > > > maybe, but why? Atomic ops are still a tad slower than normal ops and > every cycle counts in the wakeup path. Also, the solution is still not > correct, because it does not take other migration paths into account, so
Oops.
> we could end up with a sleeping task showing up on another CPU just as > well. The most robust solution is to simply not care about migration and > to care about the total count only.
Yes and, with the new comment above its declaration, if anybody (in the future) wants to use the per cpu data they will be aware that they need to modify the code if they need it to be always accurate.
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/
| |