Re: SLUB: Add Kconfig option for SLAB quirks

[Andrew Morton]

On Fri, 6 Apr 2007 12:53:22 -0700 (PDT)
Christoph Lameter <clameter@xxxxxxx> wrote:

> This patch may allow to reduce the churn for SLUB. It adds a Kconfig
> option that makes SLUB replicate SLAB special handling for slab caches.
> 
> ... 
>
> Index: linux-2.6.21-rc5-mm4/init/Kconfig
> ===================================================================
> --- linux-2.6.21-rc5-mm4.orig/init/Kconfig	2007-04-06 12:12:59.000000000 -0700
> +++ linux-2.6.21-rc5-mm4/init/Kconfig	2007-04-06 12:21:44.000000000 -0700
> @@ -569,6 +569,32 @@ config SLUB
>  	   of queues of objects. SLUB can use memory efficiently
>  	   way and has enhanced diagnostics.
>  
> +config SLUB_SLAB_QUIRKS
> +	depends on SLUB
> +	bool "SLUB: Handle SLAB quirks"
> +	help
> +	  Make SLUB emulate various inconsistent behaviors of SLAB in order
> +	  to avoid having to fix these issues. Switching this on will make
> +	  debugging on some slabs impossible and may lead to a slight
> +	  performance degradation (one additional check in the hotpath).
> +
> +	  The issues addressed are
> +	  1. Page order slabs are always aligned on page boundaries
> +	     regardless of other alignment requirements. This also
> +	     affects the kmalloc array. Kmalloc slabs are usually aligned
> +	     to KMALLOC_MINALIGN. Now we make an exception for those of
> +	     page order. Debugging options are disabled if they would
> +	     misalign a cache.
> +
> +	  2. Page order slabs are handled in such a way that page->index
> +	     can be used for other purposes.
> +
> +	  3. PAGE_SIZE slabs are never increased beyond PAGE_SIZE.
> +	     Debugging is switched off in order to guarantee that.
> +	     This allows the use of page->private for other purposes.
> +	     All slab allocators use compound pages for higher order
> +	     allocations which would no longer allow the use of page->private.

urgh.  It would be better to continue to rework slab/slub callers in the
fashion which you have been doing, don't you think?



Rephrasing my earlier point: are we doing things in the correct order here,
and efficiently?  It is not settled in my mind whether we want to merge
slub _at all_.  Do we have enough information yet to be able to make that
decision?

And if that information indicates that a slub merge _is_ justified, why is
the chosen approach superior to the incremental one: if slab code is grotty
(it is), clean it up.  If slab has unnecessary stuff, delete it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/