lkml.org 
[lkml]   [2008]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 21/21] slab defrag: Obsolete SLAB
Some more on SMP scaling:

There is also the issue in SLAB that global locks (SMP case) need to be
taken for a pretty long timeframe. With a sufficiently high allocation
frequency from multiple processors you can cause lock contention on the
list_lock that will then degrade performance.

SLUB does not take global locks for continued allocations. Global locks
are taken for a short time frame if the partial lists need to be updated
(which is avoided as much as possible with various measures). This can
yield orders of magnitude higher performance

The above is possible because of locking at the page level. A queue must
either be processor specific or global (or per node) and then would
need locks.

Another issue is storage density. SLAB needs a metadata structure that
either is placed in the slab page itself or in a separate slab cache. In
some cases this is advantageous over SLUB (f.e. a series of pointers to
objects exist in a single cacheline thus allocation of objects that are
not immediately used could be faster) in others it is not (because it
increases cache footprint, requires the touching of two slabcaches if the
metadata is off slab, makes alignment of objects in the slab pages
difficult and increases memory overhead, SLUB generally is faster if the
object is/was immediately used since the freepointer overlays the data
and thus the cacheline is hot both on alloc and free).


\
 
 \ /
  Last update: 2008-05-14 22:49    [W:0.163 / U:2.876 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site