Messages in this thread | | | Date | Mon, 28 Jul 2008 11:23:57 -0700 | From | Mike Travis <> | Subject | Re: [git pull] cpus4096 fixes |
| |
Rusty Russell wrote: > On Monday 28 July 2008 18:16:39 Ingo Molnar wrote: >> * Rusty Russell <rusty@rustcorp.com.au> wrote: >>> Mike: I now think the right long-term answer is Linus' dense cpumap >>> idea + a convenience allocator for cpumasks. We sweep the kernel for >>> all on-stack vars and replace them with one or the other. Thoughts? >> The dense cpumap for constant cpumasks is OK as it's clever, compact and >> static. >> >> All-dynamic allocator for on-stack cpumasks ... is a less obvious >> choice. > > Sorry, I was unclear. "long-term" == "more than 4096 CPUs", since I thought > that was Mike's aim. If we only want to hack up 4k CPUS and stop, then I > understand the current approach. > > If we want huge cpu numbers, I think cpumask_alloc/free gives the clearest > code. So our approach is backwards: let's do that *then* put ugly hacks in > if it's really too slow. > > Cheers, > Rusty.
Well, yes, "long-term" is not really that long and the system will be capable of supporting 16k cpus. With the limit on clock scalability, core count is going through the roof. Fortunately, we have a whole new release cycle to rethink some basic ideas.
I did bring up a number of suggestions on how to replace cpumask_t, but they all seemed to hamper small systems in one way or another. And the goal, again was to minimize impact for 99.99% of the systems that won't have a thousand or more cpus. (Though it only takes 8 Larrabee chips to attain that.)
Thanks, Mike
| |