Andrew Morton wrote: > On Thu, 29 May 2008 20:56:20 -0700 Christoph Lameter <clameter@xxxxxxx> wrote: > >> In various places the kernel maintains arrays of pointers indexed by >> processor numbers. These are used to locate objects that need to be used >> when executing on a specirfic processor. Both the slab allocator >> and the page allocator use these arrays and there the arrays are used in >> performance critical code. The allocpercpu functionality is a simple >> allocator to provide these arrays. > > All seems reasonable to me. The obvious question is "how do we size > the arena". We either waste memory or, much worse, run out. > > And running out is a real possibility, I think. Most people will only > mount a handful of XFS filesystems. But some customer will come along > who wants to mount 5,000, and distributors will need to cater for that, > but how can they? > > I wonder if we can arrange for the default to be overridden via a > kernel boot option? > > > Another obvious question is "how much of a problem will we have with > internal fragmentation"? This might be a drop-dead showstopper. One problem with variable sized cpu_alloc area is this comment in bitmap.h: * Note that nbits should be always a compile time evaluable constant. * Otherwise many inlines will generate horrible code. I'm guessing since this will be of low use and not performance critical, then we can ignore the "horrible code"? ;-) Thanks, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
