Re: Slab BUG with DEBUG_* options

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 3 Dec 2013, Christoph Lameter wrote:

> Subject: slab: Do not use off slab metadata for CONFIG_DEBUG_PAGEALLOC
>
> Signed-off-by: Christoph Lameter <cl@xxxxxxxxx>

The patch fails here at the largest slab which requires off slab
management because otherwise the order becomes too high.

The fundamental problem is that debugging increases the size of the slab
significantly so that even small slabs require slab management. But
the kmalloc slabs used for the sizes required for management objects have not
been created yet.

Slab bootstrap relies on smaller slabs not requiring slab management
slabs. Once it gets to larger sizes then smaller slab management objects
may be allocated.

However, in this case the slab sizes are required for management at early
boot after slab_early_init has been set to 0 are not available.

If the slab management sizes required match other slab caches sizes that
were already created at boot then bootstrap will succeed regardless.

I have another patch here (that I cannot test since I cannot run sparc
code) that simply changes the determination for switching slab management
to base the decision not on the final size of the slab (which is always
large in the debugging cases here) but on the initial object size. For
small objects < PAGESIZE/8 this should avoid the use of slab management
even in the debugging case.

Subject: slab: Do not use slab management for slabs with smaller objects

Use the object size to make the off slab decision instead of the final
size of the slab objects (which is large in case of
CONFIG_PAGEALLOC_DEBUG).

Signed-off-by: Christoph Lameter <cl@xxxxxxxxx>

Index: linux/mm/slab.c
===================================================================
--- linux.orig/mm/slab.c	2013-12-03 10:48:42.625823157 -0600
+++ linux/mm/slab.c	2013-12-03 10:49:06.755152653 -0600
@@ -2243,8 +2243,8 @@ __kmem_cache_create (struct kmem_cache *
 	 * it too early on. Always use on-slab management when
 	 * SLAB_NOLEAKTRACE to avoid recursive calls into kmemleak)
 	 */
-	if ((size >= (PAGE_SIZE >> 3)) && !slab_early_init &&
-	    !(flags & SLAB_NOLEAKTRACE))
+	if ((cachep->size >= (PAGE_SIZE >> 3)) && !slab_early_init &&
+	    !(flags & SLAB_NOLEAKTRACE) )
 		/*
 		 * Size is large, assume best to place the slab management obj
 		 * off-slab (should allow better packing of objs).


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]