[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0702220712440.757@schroedinger.engr.sgi.com>
Date: Thu, 22 Feb 2007 07:15:11 -0800 (PST)
From: Christoph Lameter <clameter@....com>
To: Pekka Enberg <penberg@...helsinki.fi>
cc: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: SLUB: The unqueued Slab allocator
On Thu, 22 Feb 2007, Pekka Enberg wrote:
> On 2/22/07, Christoph Lameter <clameter@....com> wrote:
> > This is a new slab allocator which was motivated by the complexity of the
> > existing code in mm/slab.c. It attempts to address a variety of concerns
> > with the existing implementation.
>
> So do you want to add a new allocator or replace slab?
Add. The performance and quality is not comparable to SLAB at this point.
> On 2/22/07, Christoph Lameter <clameter@....com> wrote:
> > B. Storage overhead of object queues
>
> Does this make sense for non-NUMA too? If not, can we disable the
> queues for NUMA in current slab?
Given the locking scheme in the current slab you cannot do that. Otherwise
there will be a single lock taken for every operation limiting performace
> On 2/22/07, Christoph Lameter <clameter@....com> wrote:
> > C. SLAB metadata overhead
>
> Can be done for the current slab code too, no?
The per slab metadata of the SLAB does not fit into the page_struct.
-
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