Messages in this thread |  | | | Date | Fri, 12 Sep 2008 15:58:14 -0700 | | From | "H. Peter Anvin" <> | | Subject | Re: [RFC] CPUMASK: proposal for replacing cpumask_t |
| |
Mike Travis wrote: > > Here's the thread: > > http://marc.info/?l=linux-kernel&m=121976977901223&w=4 > > It doesn't seem worthwhile to force all systems to deal with large cpumask's > if they don't need to. Passing the value on the stack (actually usually in a > reg) if it fits into a long makes a lot of sense. > > And I don't think it's that abstract, but I'm willing to hear other opinions. > > Btw, most likely only distros that distribute an "Enterprise" edition of > Linux will ever set NR_CPUS so high, so the actual number of systems making > use of this will be a very small percentage (big $$-wise though... ;-) > > I even think that perhaps BITS_PER_LONG might be too low a threshold to kick > in this extra code. A Larabee chip will have 128 cpus so maybe 128 or 256 is > a better metric...? > > As soon as I get a working kernel with the proposed changes, I will definitely > be doing perf testing. >
If the performance difference isn't significant, then there is a major advantage to getting rid of a configuration option. At that point we can basically scale to an arbitrary number of processors in a stock configuration.
-hpa
|  |