On Thu, 22 Feb 2007, Pekka Enberg wrote:
> On 2/22/07, Christoph Lameter <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [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]
