Hmmmm... Some tests here on an 8p 8G machine:

SLAB

N=10 Time: 0.341
N=20 Time: 0.605
N=50 Time: 1.487

SLUB 

N=10 Time: 0.675
N=20 Time: 1.434
N=50 Time: 3.996

So its factor 2 for untuned SLUB. Looking at hackbench: This is a 
test that allocates objects that are then consumed by N cpus that then 
return them. The allocating processor can allocate from the per cpu slab 
(the freelist is copied to a per cpu structure when its activated)
avoiding touching the page struct. However, the freeing processors 
must update the freelist of the slab page directly. So they all content 
for the cacheline of the page struct.

Since we do directly free there is the chance of lots of contention 
between the N cpus that free the objects. This is in particular high in a 
synthetic benchmark like this.

However, if the object to be freed is still in a cpu slab then the freeing 
action will reduce the taking of the listlock. So we can actually 
decrease the overhead by increasing the slab page size.

In an extreme case (boot with slub_min_order=9 to get huge page sized 
slabs) SLUB can win against SLAB:

N=10 Time: 0.338	Minimally faster
N=20 Time: 0.560	10% faster
N=50 Time: 1.353	15% faster

Not sure how to get that mainstream yet but there certainly is a way to 
get there. Need to get an idea how to reduce listlock contention in the 
remote free case.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/