[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070502195412.GC9044@uranus.ravnborg.org>
Date: Wed, 2 May 2007 21:54:12 +0200
From: Sam Ravnborg <sam@...nborg.org>
To: Christoph Lameter <clameter@....com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Hugh Dickins <hugh@...itas.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: 2.6.22 -mm merge plans: slub
On Wed, May 02, 2007 at 12:42:54PM -0700, Christoph Lameter wrote:
> On Wed, 2 May 2007, Andrew Morton wrote:
>
> > > At some point I dream that SLUB could become the default but I thought
> > > this would take at least 6 month or so. If want to force this now then I
> > > will certainly have some busy weeks ahead.
> >
> > s/dream/promise/ ;)
> >
> > Six months sounds reasonable - I was kind of hoping for less. Make it
> > default-to-on in 2.6.23-rc1, see how it goes.
>
> Here is how I think the future could develop
>
> Cycle SLAB SLUB SLOB SLxB
>
> 2.6.22 API fixes Stabilization API fixes
>
> Major event: SLUB availability as experimental
>
> 2.6.23 API upgrades Perf. Valid. EOL
>
> Major events: SLUB performance validation. Switch off
> experimental (could even be the default)
> Slab allocators support targeted reclaim for at
> least one slab cache (dentry?)
> (vacate/move all objects in a slab)
To facilitate this do NOT introduce CONFIG_SLAB until we decide
that SLUB are default. In this way we can make CONFIG_SLUB be default
and people will not continue with CONFIG_SLAB because they had it in their
.config already.
Or just rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED or something.
The point is make sure that LSUB becomes default for people that does
an make oldconfig (explicit or implicit).
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists