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

Christoph Lameter
2008-05-15T17:15:47Z

On Wed, 14 May 2008, Matt Mackall wrote:

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

Both allocators have a different design which leads to different behavior.
I do not think the expectation that one must always best the other is
reasonable or even possible.

I'd be glad if we had some means of increasing the performance in the
currently known cases where remote slab free becomes an issue by avoiding
the atomic op.

AFAICT we so far have been able to compensate for the additional atomic op
with a reduced cache footprint and less complexity overall on remote frees
and also through improvements in alloc behavior. I hope that the current
improvements in 2.6.26 are sufficient to address the concerns with TP-C
(which I do not have direct access to and frankly I know very little about
the setup etc). We are still not sure exactly why TP-C has a problem. The
slab statistics were added to figure that one out. We can get a view of
what is going on without having access to the system.

I think the current way of compensating for that atomic op is better than
getting back to the queue mess. Maybe there is a way of limited use of
queues that avoids the atomic op but so far I have not
found one. Maybe someone else looking at it will have better ideas.