Re: [patch 21/21] slab defrag: Obsolete SLAB

[Matt Mackall <mpm@selenic.com>]

On Wed, 2008-05-14 at 14:26 -0700, Christoph Lameter wrote:
> > So far this is a bunch of hand-waving but I think this ends up
> basically
> > being an anti-magazine. A magazine puts a per-cpu queue on the alloc
> > side which costs on both the alloc and free side, regardless of whether
> > the workload demands it. This puts a per-cpu queue on the free side that
> > we can bypass in the cache-friendly case. I think that's a step in the
> > right direction.
> 
> I think if you want queues for an SMP only system, do not care too much 
> about memory use, dont do any frequent allocations on multicore systems 
> and can tolerate the hiccups because your application does not care (most 
> enterprise apps are constructed that way) or if you are running benchmarks 
> that only access a limited dataset that fits into SLABs queues amd 
> avoid touch the contenst of objects then the SLAB concept is the right way 
> to go.

> If we would strip the NUMA stuff out and make it an SMP only allocator for 
> enterprise apps then the code may become much smaller and simpler. I guess 
> Arjan suggested something similar in the past. But that would result in 
> SLAB no longer being a general allocator.

What does this have to do with anything? I'm not talking about going
back to SLAB. I'm talking about plugging the use cases where SLUB
currently loses to SLAB. That's what has to happen before SLAB can be
obsoleted.

I'll certainly grant you that queueing might not break even.

-- 
Mathematics is the supreme nostalgia of our time.