Messages in this thread | | | From | (bill davidsen) | Subject | Re: [PATCH][RFC] make cpu_sibling_map a cpumask_t | Date | 11 Dec 2003 21:41:39 GMT |
| |
In article <3FD5CFE1.8080800@cyberone.com.au>, Nick Piggin <piggin@cyberone.com.au> wrote:
| Well if (something like) cpu_sibling_map is to become architecture | independant code, it should probably get something like cpu_to_package, | package_to_cpumask sort of things like NUMA has. | | I don't know if SMT should become just another level of NUMA because | its not NUMA of course. For the scheduler it seems to make sense because | SMT/SMP/NUMA basically want slight variations of the same thing. | | Possibly as you say slab cache could be SMTed, but I'm not convinced | that SMT and NUMA should become inseperable. Anyway I doubt 2.6 will | see a general multi level NUMA framework.
It would seem that what concerns all of these levels is the process migration cost, so perhaps it will be possible in 2.6 after all. Right now a lot of clever people are actively working on scheduling, so now is the time for a breakthrough which gives a big boost. Absent that I predict all of the clever folks and most of us "build a bunch of kernels and play" types will conclude the low hanging fruit have all been picked and move on. Scheduling will be stable again.
Before that perhaps one of you will suddenly see some way to make this all very simple and elegant, so everyone can look and say "of course" and everything will work optimally.
What we have in all of these patches is a big gain over base, so the efforts have produced visable gains. -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - 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/
| |