![]() | ||||||||||
Messages in this thread |
Andi Kleen wrote: > On Tue, 30 Mar 2004 09:51:46 +1000 > Nick Piggin <nickpiggin@yahoo.com.au> wrote: > > > >>So both -mm5 and Ingo's sched.patch are much worse than >>what 2.4 and 2.6 get? > > > Yes (2.6 vanilla and 2.4-aa at that, i haven't tested 2.4-vanilla) > > Ingo's sched.patch makes it a bit better (from 1x CPU to 1.5-1.7xCPU), but still > much worse than the max of 3.7x-4x CPU bandwidth. > So it is very likely to be a case of the threads running too long on one CPU before being balanced off, and faulting in most of their working memory from one node, right? I think it is impossible for the scheduler to correctly identify this and implement the behaviour that OpenMP wants without causing regressions on more general workloads (Assuming this is the problem). We are not going to go back to the wild balancing that numasched does (I have some benchmarks where sched-domains reduces cross node task movement by several orders of magnitude). So the other option is to do balance on clone across NUMA nodes, and make it very sensitive to imbalance. Or probably better to make it easy to balance off to an idle CPU, but much more difficult to balance off to a busy CPU. I suspect this would still be a regression for other tests though where thread creation is more frequent, threads share working set more often, or the number of threads > the number of CPUs. - 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/ | |||||||||
| Last update: 2005-03-22 13:02 [from the cache] ©2003-2008 | ||||||||||