Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [PATCH] 2.5.21 Nonlinear CPU support | Date | Wed, 12 Jun 2002 15:57:08 +1000 |
| |
In message <5.1.0.14.2.20020611120032.00aec7f0@pop.cus.cam.ac.uk> you write: > >In which case, CONFIG_NR_CPUS is the only way to get the memory > >back... > > Why? You can get rid of all uses of NR_CPUS (except for using it as a max > capping value so none goes above it) and always use smp_num_cpus instead. > And make the cpu hotplug code update smp_num_cpus as appropriate.
You remove CPU 2 of 4 and the others renumber? Everyone using per-cpu buffers needs to write code to move them. And what do apps bound to CPU 3 do? What about *their* per-cpu data structures?
> So zero penalty for non-hotplug users and loads of penalty for hotplug > users but frankly I couldn't care less for those. The slow path will > trigger so seldom it is not worth thinking about the performance hit there.
And a greater requirement for everyone using per-cpu buffers (which are becoming more common, not less) to write more code. And it doesn't deal with CPU removal.
> There are a lot of ways to deal with this corner case dynamically, so > please use one of them. I don't buy the "lets penalise 99% of users for the > sake of a feature that almost noone will ever use" argument.
Sorry, you're arguing to maintain a traditionally problematic interface for an unmeasurable time benifit, and a slight space benefit (on SMP machines, where noone has cared space about until recently).
Now, you *could* only allocate buffers for cpus where cpu_possible(i) is true, once the rest of the patch goes in. That would be a valid optimization.
Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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/
| |