Re: SLUB: Add Kconfig option for SLAB quirks

[Christoph Lameter <clameter@sgi.com>]

On Fri, 6 Apr 2007, Andrew Morton wrote:

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

Yes definitely but I do not want to risk getting slub dropped from mm.

> 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?

Check the initial SLUB_V6 patch? It has long list of issues that were 
addressed.

> 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.

SLUB is a fundamentally different design. We can address some of the 
warts in SLAB as we do the cleanup but the basic way of handling objects 
on queues is core to SLAB and is not used at all in SLUB.

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