Re: slab hang on boot

Re: slab hang on boot

[David Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Mon, 14 May 2007 21:36:42 +0300 (EEST)

> Sorry, I could not test the parport patch yet - I did git upgrade as of 
> yesterday and the kernel hangs on boot. boot -p reveals the following 
> slab panic:

Please enable SLUB to work around this for now, SLAB wants
LARGE_ALLOCS enabled when it really shouldn't require that
for a 512K or 1MB SLAB when PAGE_SIZE==8192 :-(

> kmem_cache_create: Early error in slab tsb_512KB
> kernel BUG at mm/slab.c:2165!

Christoph, this is why I had to have LARGE_ALLOCS enabled on sparc64
all this time, for that MAX_OBJ_ORDER logic in mm/slab.c in order
to get 512K and 1MB slab caches usable.

This inconsistency is painful for platforms.  If I enable LARGE_ALLOCS
on sparc64 then SLAB works but it's a total waste for SLUB.

Right now if I enable LARGE_ALLOCS, SLUB will break again due to
that KMALLOC_SHIFT_HIGH bug we fixed the other week, Christophe
can you at least push that fix to Linus if you haven't already?

Thanks.

Re: slab hang on boot

[Christoph Lameter]

On Mon, 14 May 2007, David Miller wrote:

> From: Meelis Roos <mroos@linux.ee>
> Date: Mon, 14 May 2007 21:36:42 +0300 (EEST)
> 
> > Sorry, I could not test the parport patch yet - I did git upgrade as of 
> > yesterday and the kernel hangs on boot. boot -p reveals the following 
> > slab panic:
> 
> Please enable SLUB to work around this for now, SLAB wants
> LARGE_ALLOCS enabled when it really shouldn't require that
> for a 512K or 1MB SLAB when PAGE_SIZE==8192 :-(

Ok.

> > kmem_cache_create: Early error in slab tsb_512KB
> > kernel BUG at mm/slab.c:2165!
> 
> Christoph, this is why I had to have LARGE_ALLOCS enabled on sparc64
> all this time, for that MAX_OBJ_ORDER logic in mm/slab.c in order
> to get 512K and 1MB slab caches usable.

Hmmm... The #ifdef crap there has worried me for a long time. Lets try to 
clear that mess up too.
 
> This inconsistency is painful for platforms.  If I enable LARGE_ALLOCS
> on sparc64 then SLAB works but it's a total waste for SLUB.
> 
> Right now if I enable LARGE_ALLOCS, SLUB will break again due to
> that KMALLOC_SHIFT_HIGH bug we fixed the other week, Christophe
> can you at least push that fix to Linus if you haven't already?

No I thought you had it under control so I held it in my tree.

Andrew please push this patch upstream.



SLUB: CONFIG_LARGE_ALLOCS must consider MAX_ORDER limit

Take MAX_ORDER into consideration when determing KMALLOC_SHIFT_HIGH.
Otherwise we may run into a situation where we attempt to create
general slabs larger than MAX_ORDER.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

---
 include/linux/slub_def.h |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Index: slub/include/linux/slub_def.h
===================================================================
--- slub.orig/include/linux/slub_def.h	2007-05-10 15:19:39.000000000 -0700
+++ slub/include/linux/slub_def.h	2007-05-10 16:06:15.000000000 -0700
@@ -59,7 +59,8 @@ struct kmem_cache {
 #define KMALLOC_SHIFT_LOW 3
 
 #ifdef CONFIG_LARGE_ALLOCS
-#define KMALLOC_SHIFT_HIGH 25
+#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT) =< 25 ? \
+				MAX_ORDER + PAGE_SHIFT - 1 : 25)
 #else
 #if !defined(CONFIG_MMU) || NR_CPUS > 512 || MAX_NUMNODES > 256
 #define KMALLOC_SHIFT_HIGH 20
@@ -86,6 +87,9 @@ static inline int kmalloc_index(int size
 	 */
 	WARN_ON_ONCE(size == 0);
 
+	if (size >= (1UL << KMALLOC_SHIFT_HIGH))
+		return -1;
+
 	if (size > 64 && size <= 96)
 		return 1;
 	if (size > 128 && size <= 192)

Re: slab hang on boot

[Andrew Morton]

On Mon, 14 May 2007 16:46:17 -0700 (PDT)
Christoph Lameter <clameter@sgi.com> wrote:

> -#define KMALLOC_SHIFT_HIGH 25
> +#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT) =< 25 ? \
> +				MAX_ORDER + PAGE_SHIFT - 1 : 25)

Would prefer to see a lot more parentheses in there.  Who knows what the arch
is using for MAX_ORDER and PAGE_SHIFT.

>  #if !defined(CONFIG_MMU) || NR_CPUS > 512 || MAX_NUMNODES > 256
>  #define KMALLOC_SHIFT_HIGH 20
> @@ -86,6 +87,9 @@ static inline int kmalloc_index(int size
>  	 */
>  	WARN_ON_ONCE(size == 0);
>  
> +	if (size >= (1UL << KMALLOC_SHIFT_HIGH))
> +		return -1;
> +

`size' is `int'.  Deliberately comparing it to an unsigned long seems
unpointful.

Arguably, `size' should be size_t.

Re: slab hang on boot

[Andrew Morton]

On Mon, 14 May 2007 16:46:17 -0700 (PDT)
Christoph Lameter <clameter@sgi.com> wrote:

> @@ -86,6 +87,9 @@ static inline int kmalloc_index(int size
>  	 */
>  	WARN_ON_ONCE(size == 0);
>  
> +	if (size >= (1UL << KMALLOC_SHIFT_HIGH))
> +		return -1;
> +

I don't quite understand why we did this.  The subsequent logic in
kmalloc_index() should return -1 for this `size' anyway.  If it doesn't,
it's bust, isn't it?

Also, afaict kmalloc_slab() will totally mishandle the -1 return value and
will return a garbage kmem_cache*, via

        return &kmalloc_caches[index];


Could you double-check it all please?

Re: slab hang on boot

[Christoph Lameter]

On Tue, 15 May 2007, Andrew Morton wrote:

> On Mon, 14 May 2007 16:46:17 -0700 (PDT)
> Christoph Lameter <clameter@sgi.com> wrote:
> 
> > @@ -86,6 +87,9 @@ static inline int kmalloc_index(int size
> >  	 */
> >  	WARN_ON_ONCE(size == 0);
> >  
> > +	if (size >= (1UL << KMALLOC_SHIFT_HIGH))
> > +		return -1;
> > +
> 
> I don't quite understand why we did this.  The subsequent logic in
> kmalloc_index() should return -1 for this `size' anyway.  If it doesn't,
> it's bust, isn't it?

KMALLOC_SHIFT_HIGH is not a constant but may be less than 25.

> Also, afaict kmalloc_slab() will totally mishandle the -1 return value and
> will return a garbage kmem_cache*, via
> 
>         return &kmalloc_caches[index];

It does an

if (index < 0)

before getting to that statement.
 
> Could you double-check it all please?

It was already checked.


 

Re: slab hang on boot

[Andrew Morton]

On Tue, 15 May 2007 16:45:22 -0700 (PDT)
Christoph Lameter <clameter@sgi.com> wrote:

> On Tue, 15 May 2007, Andrew Morton wrote:
> 
> > On Mon, 14 May 2007 16:46:17 -0700 (PDT)
> > Christoph Lameter <clameter@sgi.com> wrote:
> > 
> > > @@ -86,6 +87,9 @@ static inline int kmalloc_index(int size
> > >  	 */
> > >  	WARN_ON_ONCE(size == 0);
> > >  
> > > +	if (size >= (1UL << KMALLOC_SHIFT_HIGH))
> > > +		return -1;
> > > +
> > 
> > I don't quite understand why we did this.  The subsequent logic in
> > kmalloc_index() should return -1 for this `size' anyway.  If it doesn't,
> > it's bust, isn't it?
> 
> KMALLOC_SHIFT_HIGH is not a constant but may be less than 25.

It darn well better be a compile-time constant.

And look:

static inline int kmalloc_index(int size)
{
	/*
	 * We should return 0 if size == 0 but we use the smallest object
	 * here for SLAB legacy reasons.
	 */
	WARN_ON_ONCE(size == 0);

	if (size > (1 << KMALLOC_SHIFT_HIGH))
		return -1;

	if (size > 64 && size <= 96)
		return 1;
	if (size > 128 && size <= 192)
		return 2;
	if (size <=          8) return 3;
	if (size <=         16) return 4;
	if (size <=         32) return 5;
	if (size <=         64) return 6;
	if (size <=        128) return 7;
	if (size <=        256) return 8;
	if (size <=        512) return 9;
	if (size <=       1024) return 10;
	if (size <=   2 * 1024) return 11;
	if (size <=   4 * 1024) return 12;
	if (size <=   8 * 1024) return 13;
	if (size <=  16 * 1024) return 14;
	if (size <=  32 * 1024) return 15;
	if (size <=  64 * 1024) return 16;
	if (size <= 128 * 1024) return 17;
	if (size <= 256 * 1024) return 18;
#if KMALLOC_SHIFT_HIGH > 18
	if (size <=  512 * 1024) return 19;
	if (size <= 1024 * 1024) return 20;
#endif
#if KMALLOC_SHIFT_HIGH > 20
	if (size <=  2 * 1024 * 1024) return 21;
	if (size <=  4 * 1024 * 1024) return 22;
	if (size <=  8 * 1024 * 1024) return 23;
	if (size <= 16 * 1024 * 1024) return 24;
	if (size <= 32 * 1024 * 1024) return 25;
#endif
	return -1;

/*
 * What we really wanted to do and cannot do because of compiler issues is:
 *	int i;
 *	for (i = KMALLOC_SHIFT_LOW; i <= KMALLOC_SHIFT_HIGH; i++)
 *		if (size <= (1 << i))
 *			return i;
 */
}

Either that newly-added test isn't needed, or those ifdefs aren't needed?

Re: slab hang on boot

[David Miller]

From: Andrew Morton <akpm@linux-foundation.org>
Date: Tue, 15 May 2007 16:56:36 -0700

> On Tue, 15 May 2007 16:45:22 -0700 (PDT)
> Christoph Lameter <clameter@sgi.com> wrote:
> 
> > KMALLOC_SHIFT_HIGH is not a constant but may be less than 25.
> 
> It darn well better be a compile-time constant.

Try to define a compile-time array size with it smarty
pants :-)

That's what we did initially and it doesn't work.

Re: slab hang on boot

[Andrew Morton]

On Tue, 15 May 2007 17:14:47 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Tue, 15 May 2007 16:56:36 -0700
> 
> > On Tue, 15 May 2007 16:45:22 -0700 (PDT)
> > Christoph Lameter <clameter@sgi.com> wrote:
> > 
> > > KMALLOC_SHIFT_HIGH is not a constant but may be less than 25.
> > 
> > It darn well better be a compile-time constant.
> 
> Try to define a compile-time array size with it smarty
> pants :-)

confusedy pants, more like.

> That's what we did initially and it doesn't work.

This:

struct kmem_cache kmalloc_caches[KMALLOC_SHIFT_HIGH + 1] __cacheline_aligned;

is still there.

Re: slab hang on boot

[David Miller]

From: Andrew Morton <akpm@linux-foundation.org>
Date: Tue, 15 May 2007 17:29:57 -0700

> This:
> 
> struct kmem_cache kmalloc_caches[KMALLOC_SHIFT_HIGH + 1] __cacheline_aligned;
> 
> is still there.

My bad, we tried using min_t() and that's what caused the problems,
that's why we open-coded the macro like it is now :-)

Re: slab hang on boot

[Christoph Lameter]

Here is the patch. It probably does not apply cleanly against Andrew's 
tree. I am waiting for the new tree in order to submit it.


Slab allocators: Define common size limitations

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
possible 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 th past)

Most architectures will then be able to allocate object sizes up to MAX_ORDER.
We have had repeated breakage on IA64 because a NUMA structure grew beyond
what the slab allocators supported. This will avoid future issues.

CONFIG_LARGE_ALLOCS is no longer necessary so drop it.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

---
 arch/blackfin/Kconfig         |    8 --------
 arch/frv/Kconfig              |    8 --------
 arch/m68knommu/Kconfig        |    8 --------
 arch/sparc64/Kconfig          |    3 ---
 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 ++-----------------
 9 files changed, 34 insertions(+), 74 deletions(-)

Index: slub/include/linux/slab.h
===================================================================
--- slub.orig/include/linux/slab.h	2007-05-14 17:26:56.000000000 -0700
+++ slub/include/linux/slab.h	2007-05-15 17:57:42.000000000 -0700
@@ -77,6 +77,21 @@ static inline void *kmem_cache_alloc_nod
 #endif
 
 /*
+ * The largest kmalloc size supported by the slab allocators is
+ * 32 megabyte (2^25) or the maximum allocatable page order if that is
+ * less than 32 MB.
+ *
+ * WARNING: Its not easy to increase this value since the allocators have
+ * to do various tricks to work around compiler limitations in order to
+ * ensure proper constant folding.
+ */
+#define KMALLOC_SHIFT_HIGH	((MAX_ORDER + PAGE_SHIFT) <= 25 ? \
+				(MAX_ORDER + PAGE_SHIFT) : 25)
+
+#define KMALLOC_MAX_SIZE	(1UL << KMALLOC_SHIFT_HIGH)
+#define KMALLOC_MAX_ORDER	(KMALLOC_SHIFT_HIGH - PAGE_SHIFT)
+
+/*
  * Common kmalloc functions provided by all allocators
  */
 void *__kmalloc(size_t, gfp_t);
Index: slub/include/linux/slub_def.h
===================================================================
--- slub.orig/include/linux/slub_def.h	2007-05-14 17:26:56.000000000 -0700
+++ slub/include/linux/slub_def.h	2007-05-15 17:58:10.000000000 -0700
@@ -58,17 +58,6 @@ struct kmem_cache {
  */
 #define KMALLOC_SHIFT_LOW 3
 
-#ifdef CONFIG_LARGE_ALLOCS
-#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT) < 25 ? \
-				MAX_ORDER + PAGE_SHIFT - 1 : 25)
-#else
-#if !defined(CONFIG_MMU) || NR_CPUS > 512 || MAX_NUMNODES > 256
-#define KMALLOC_SHIFT_HIGH 20
-#else
-#define KMALLOC_SHIFT_HIGH 18
-#endif
-#endif
-
 /*
  * We keep the general caches in an array of slab caches that are used for
  * 2^x bytes of allocations.
@@ -79,7 +68,7 @@ extern struct kmem_cache kmalloc_caches[
  * Sorry that the following has to be that ugly but some versions of GCC
  * have trouble with constant propagation and loops.
  */
-static inline int kmalloc_index(int size)
+static inline int kmalloc_index(size_t size)
 {
 	/*
 	 * We should return 0 if size == 0 but we use the smallest object
@@ -87,7 +76,7 @@ static inline int kmalloc_index(int size
 	 */
 	WARN_ON_ONCE(size == 0);
 
-	if (size >= (1UL << KMALLOC_SHIFT_HIGH))
+	if (size > KMALLOC_MAX_SIZE)
 		return -1;
 
 	if (size > 64 && size <= 96)
@@ -110,17 +99,13 @@ static inline int kmalloc_index(int size
 	if (size <=  64 * 1024) return 16;
 	if (size <= 128 * 1024) return 17;
 	if (size <= 256 * 1024) return 18;
-#if KMALLOC_SHIFT_HIGH > 18
 	if (size <=  512 * 1024) return 19;
 	if (size <= 1024 * 1024) return 20;
-#endif
-#if KMALLOC_SHIFT_HIGH > 20
 	if (size <=  2 * 1024 * 1024) return 21;
 	if (size <=  4 * 1024 * 1024) return 22;
 	if (size <=  8 * 1024 * 1024) return 23;
 	if (size <= 16 * 1024 * 1024) return 24;
 	if (size <= 32 * 1024 * 1024) return 25;
-#endif
 	return -1;
 
 /*
Index: slub/include/linux/kmalloc_sizes.h
===================================================================
--- slub.orig/include/linux/kmalloc_sizes.h	2007-05-14 17:26:56.000000000 -0700
+++ slub/include/linux/kmalloc_sizes.h	2007-05-14 18:42:45.000000000 -0700
@@ -19,17 +19,27 @@
 	CACHE(32768)
 	CACHE(65536)
 	CACHE(131072)
-#if (NR_CPUS > 512) || (MAX_NUMNODES > 256) || !defined(CONFIG_MMU)
+#if KMALLOC_MAX_SIZE >= 262144
 	CACHE(262144)
 #endif
-#ifndef CONFIG_MMU
+#if KMALLOC_MAX_SIZE >= 524288
 	CACHE(524288)
+#endif
+#if KMALLOC_MAX_SIZE >= 1048576
 	CACHE(1048576)
-#ifdef CONFIG_LARGE_ALLOCS
+#endif
+#if KMALLOC_MAX_SIZE >= 2097152
 	CACHE(2097152)
+#endif
+#if KMALLOC_MAX_SIZE >= 4194304
 	CACHE(4194304)
+#endif
+#if KMALLOC_MAX_SIZE >= 8388608
 	CACHE(8388608)
+#endif
+#if KMALLOC_MAX_SIZE >= 16777216
 	CACHE(16777216)
+#endif
+#if KMALLOC_MAX_SIZE >= 33554432
 	CACHE(33554432)
-#endif /* CONFIG_LARGE_ALLOCS */
-#endif /* CONFIG_MMU */
+#endif
Index: slub/mm/slab.c
===================================================================
--- slub.orig/mm/slab.c	2007-05-14 17:26:56.000000000 -0700
+++ slub/mm/slab.c	2007-05-15 15:39:47.000000000 -0700
@@ -569,21 +569,6 @@ static void **dbg_userword(struct kmem_c
 #endif
 
 /*
- * Maximum size of an obj (in 2^order pages) and absolute limit for the gfp
- * order.
- */
-#if defined(CONFIG_LARGE_ALLOCS)
-#define	MAX_OBJ_ORDER	13	/* up to 32Mb */
-#define	MAX_GFP_ORDER	13	/* up to 32Mb */
-#elif defined(CONFIG_MMU)
-#define	MAX_OBJ_ORDER	5	/* 32 pages */
-#define	MAX_GFP_ORDER	5	/* 32 pages */
-#else
-#define	MAX_OBJ_ORDER	8	/* up to 1Mb */
-#define	MAX_GFP_ORDER	8	/* up to 1Mb */
-#endif
-
-/*
  * Do not go above this order unless 0 objects fit into the slab.
  */
 #define	BREAK_GFP_ORDER_HI	1
@@ -2001,7 +1986,7 @@ static size_t calculate_slab_order(struc
 	size_t left_over = 0;
 	int gfporder;
 
-	for (gfporder = 0; gfporder <= MAX_GFP_ORDER; gfporder++) {
+	for (gfporder = 0; gfporder <= KMALLOC_MAX_ORDER; gfporder++) {
 		unsigned int num;
 		size_t remainder;
 
@@ -2147,7 +2132,7 @@ kmem_cache_create (const char *name, siz
 	 * Sanity checks... these are all serious usage bugs.
 	 */
 	if (!name || in_interrupt() || (size < BYTES_PER_WORD) ||
-	    (size > (1 << MAX_OBJ_ORDER) * PAGE_SIZE) || dtor) {
+	    size > KMALLOC_MAX_SIZE || dtor) {
 		printk(KERN_ERR "%s: Early error in slab %s\n", __FUNCTION__,
 				name);
 		BUG();
Index: slub/arch/blackfin/Kconfig
===================================================================
--- slub.orig/arch/blackfin/Kconfig	2007-05-14 17:30:31.000000000 -0700
+++ slub/arch/blackfin/Kconfig	2007-05-14 17:30:45.000000000 -0700
@@ -560,14 +560,6 @@ endchoice
 
 source "mm/Kconfig"
 
-config LARGE_ALLOCS
-	bool "Allow allocating large blocks (> 1MB) of memory"
-	help
-	  Allow the slab memory allocator to keep chains for very large
-	  memory sizes - upto 32MB. You may need this if your system has
-	  a lot of RAM, and you need to able to allocate very large
-	  contiguous chunks. If unsure, say N.
-
 config BFIN_DMA_5XX
 	bool "Enable DMA Support"
 	depends on (BF533 || BF532 || BF531 || BF537 || BF536 || BF534 || BF561)
Index: slub/arch/frv/Kconfig
===================================================================
--- slub.orig/arch/frv/Kconfig	2007-05-14 17:30:32.000000000 -0700
+++ slub/arch/frv/Kconfig	2007-05-14 17:31:08.000000000 -0700
@@ -102,14 +102,6 @@ config HIGHPTE
 	  with a lot of RAM, this can be wasteful of precious low memory.
 	  Setting this option will put user-space page tables in high memory.
 
-config LARGE_ALLOCS
-	bool "Allow allocating large blocks (> 1MB) of memory"
-	help
-	  Allow the slab memory allocator to keep chains for very large memory
-	  sizes - up to 32MB. You may need this if your system has a lot of
-	  RAM, and you need to able to allocate very large contiguous chunks.
-	  If unsure, say N.
-
 source "mm/Kconfig"
 
 choice
Index: slub/arch/m68knommu/Kconfig
===================================================================
--- slub.orig/arch/m68knommu/Kconfig	2007-05-14 17:30:32.000000000 -0700
+++ slub/arch/m68knommu/Kconfig	2007-05-14 17:31:16.000000000 -0700
@@ -470,14 +470,6 @@ config AVNET
 	default y
 	depends on (AVNET5282)
 
-config LARGE_ALLOCS
-	bool "Allow allocating large blocks (> 1MB) of memory"
-	help
-	  Allow the slab memory allocator to keep chains for very large
-	  memory sizes - upto 32MB. You may need this if your system has
-	  a lot of RAM, and you need to able to allocate very large
-	  contiguous chunks. If unsure, say N.
-
 config 4KSTACKS
 	bool "Use 4Kb for kernel stacks instead of 8Kb"
 	default y
Index: slub/arch/sparc64/Kconfig
===================================================================
--- slub.orig/arch/sparc64/Kconfig	2007-05-14 17:30:32.000000000 -0700
+++ slub/arch/sparc64/Kconfig	2007-05-14 17:31:24.000000000 -0700
@@ -226,9 +226,6 @@ config ARCH_SPARSEMEM_DEFAULT
 	def_bool y
 	select SPARSEMEM_STATIC
 
-config LARGE_ALLOCS
-	def_bool y
-
 source "mm/Kconfig"
 
 config ISA
Index: slub/arch/v850/Kconfig
===================================================================
--- slub.orig/arch/v850/Kconfig	2007-05-14 17:30:32.000000000 -0700
+++ slub/arch/v850/Kconfig	2007-05-14 17:31:33.000000000 -0700
@@ -240,14 +240,6 @@ menu "Processor type and features"
    config RESET_GUARD
    	  bool "Reset Guard"
 
-   config LARGE_ALLOCS
-	  bool "Allow allocating large blocks (> 1MB) of memory"
-	  help
-	     Allow the slab memory allocator to keep chains for very large
-	     memory sizes - upto 32MB. You may need this if your system has
-	     a lot of RAM, and you need to able to allocate very large
-	     contiguous chunks. If unsure, say N.
-
 source "mm/Kconfig"
 
 endmenu

Re: slab hang on boot

[David Miller]

From: Christoph Lameter <clameter@sgi.com>
Date: Tue, 15 May 2007 18:00:23 -0700 (PDT)

> Slab allocators: Define common size limitations

Thanks for doing this work Christoph, I'll test this patch out on all
my sparc64 boxes, with both SLAB and SLUB, later this evening.

Re: slab hang on boot

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Tue, 15 May 2007 18:03:16 -0700 (PDT)

> From: Christoph Lameter <clameter@sgi.com>
> Date: Tue, 15 May 2007 18:00:23 -0700 (PDT)
> 
> > Slab allocators: Define common size limitations
> 
> Thanks for doing this work Christoph, I'll test this patch out on all
> my sparc64 boxes, with both SLAB and SLUB, later this evening.

SLAB works properly again on sparc64 with this patch, thanks
Christophe.

Signed-off-by: David S. Miller <davem@davemloft.net>

Re: slab hang on boot

[Christoph Lameter]

On Tue, 15 May 2007, Andrew Morton wrote:

> > Try to define a compile-time array size with it smarty
> > pants :-)
> 
> confusedy pants, more like.
> 
> > That's what we did initially and it doesn't work.
> 
> This:
> 
> struct kmem_cache kmalloc_caches[KMALLOC_SHIFT_HIGH + 1] __cacheline_aligned;
> 
> is still there.

This works fine. Please have a look at the RFC that gets rid of the mess.

Re: slab hang on boot

[Christoph Lameter]

On Tue, 15 May 2007, Andrew Morton wrote:

> Either that newly-added test isn't needed, or those ifdefs aren't needed?

The #ifdefs dont do the proper job thus the hack for Dave. The following 
RFC will clean things up.

http://marc.info/?l=linux-kernel&m=117919444827939&w=2