Re: [RFC V2 SLEB 00/14] The Enhanced(hopefully) Slab Allocator

[Christoph Lameter <cl@linux-foundation.org>]

On Fri, 28 May 2010, Nick Piggin wrote:

> > > realized that incremental improvements to SLAB would likely be a
> > > far better idea.
> >
> > It looked to me as if there was a major conceptual issue with the linked
> > lists used for objects that impacted performance
>
> With SLQB's linked list? No. Single threaded cache hot performance was
> the same (+/- a couple of cycles IIRC) as SLUB on your microbenchmark.
> On Intel's OLTP workload it was as good as SLAB.
>
> The linked lists were similar to SLOB/SLUB IIRC.

Yes that is the problem. So it did not address the cache cold
regressions in SLUB. SLQB mostly addressed the slow path frequency on
free.

The design of SLAB is superior for cache cold objects since SLAB does
not touch the objects on alloc and free (if one requires similar
cache cold performance from other slab allocators) thats why I cleaned
up the per cpu queueing concept in SLAB (easy now with the percpu
allocator and operations) and came up with SLEB. At the same time this
also addresses the slowpath issues on free. I am not entirely sure how to
deal with the NUMAness but I want to focus more on machines with low node
counts.

The problem with SLAB was that so far the "incremental improvements" have
lead to more deteriorations in the maintainability of the code. There are
multiple people who have tried going this route that you propose.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>