lkml.org 
[lkml]   [2007]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Major regression on hackbench with SLUB (more numbers)
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.


\
 
 \ /
  Last update: 2007-12-14 05:43    [W:0.149 / U:0.876 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site