On Tue, 15 May 2007 23:15:24 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> wrote:
> Currently we have a maze of configuration variables that determine > the maximum slab size. Worst of all it seems to vary between SLAB and SLUB. > > So define a common maximum size for kmalloc. For conveniences sake > we use the maximum size ever supported which is 32 MB. We limit the maximum > size to a lower limit if MAX_ORDER does not allow such large allocations. > > For many architectures this patch will have the effect of adding large > kmalloc sizes. x86_64 adds 5 new kmalloc sizes. So a small amount > of memory will be needed for these caches (contemporary SLAB has dynamically > sizeable node and cpu structure so the waste is less than in the past) > > Most architectures will then be able to allocate object with sizes up to > MAX_ORDER. We have had repeated breakage (in fact whenever we doubled the > number of supported processors) on IA64 because one or the other struct > grew beyond what the slab allocators supported. This will avoid future > issues and f.e. avoid fixes for 2k and 4k cpu support. > > CONFIG_LARGE_ALLOCS is no longer necessary so drop it. > > Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> > > --- > arch/blackfin/Kconfig | 8 -------- > arch/frv/Kconfig | 8 -------- > arch/m68knommu/Kconfig | 8 -------- > arch/v850/Kconfig | 8 -------- > include/linux/kmalloc_sizes.h | 20 +++++++++++++++----- > include/linux/slab.h | 15 +++++++++++++++ > include/linux/slub_def.h | 19 ++----------------- > mm/slab.c | 19 ++----------------- > 8 files changed, 34 insertions(+), 71 deletions(-) rofl. Really we shouldn't put this into 2.6.22, but it turfs out so much crap that it's hard to justify holding it back. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/