On Fri, 6 Apr 2007 12:53:22 -0700 (PDT)
Christoph Lameter <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
