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/
