Documentation/vm/slub.txt

   1 Short users guide for SLUB
   2 --------------------------
   3
   4 First of all slub should transparently replace SLAB. If you enable
   5 SLUB then everything should work the same (Note the word "should".
   6 There is likely not much value in that word at this point).
   7
   8 The basic philosophy of SLUB is very different from SLAB. SLAB
   9 requires rebuilding the kernel to activate debug options for all
  10 SLABS. SLUB always includes full debugging but its off by default.
  11 SLUB can enable debugging only for selected slabs in order to avoid
  12 an impact on overall system performance which may make a bug more
  13 difficult to find.
  14
  15 In order to switch debugging on one can add a option "slub_debug"
  16 to the kernel command line. That will enable full debugging for
  17 all slabs.
  18
  19 Typically one would then use the "slabinfo" command to get statistical
  20 data and perform operation on the slabs. By default slabinfo only lists
  21 slabs that have data in them. See "slabinfo -h" for more options when
  22 running the command. slabinfo can be compiled with
  23
  24 gcc -o slabinfo Documentation/vm/slabinfo.c
  25
  26 Some of the modes of operation of slabinfo require that slub debugging
  27 be enabled on the command line. F.e. no tracking information will be
  28 available without debugging on and validation can only partially
  29 be performed if debugging was not switched on.
  30
  31 Some more sophisticated uses of slub_debug:
  32 -------------------------------------------
  33
  34 Parameters may be given to slub_debug. If none is specified then full
  35 debugging is enabled. Format:
  36
  37 slub_debug=<Debug-Options>       Enable options for all slabs
  38 slub_debug=<Debug-Options>,<slab name>
  39                                 Enable options only for select slabs
  40
  41 Possible debug options are
  42         F               Sanity checks on (enables SLAB_DEBUG_FREE. Sorry
  43                         SLAB legacy issues)
  44         Z               Red zoning
  45         P               Poisoning (object and padding)
  46         U               User tracking (free and alloc)
  47         T               Trace (please only use on single slabs)
  48
  49 F.e. in order to boot just with sanity checks and red zoning one would specify:
  50
  51         slub_debug=FZ
  52
  53 Trying to find an issue in the dentry cache? Try
  54
  55         slub_debug=,dentry_cache
  56
  57 to only enable debugging on the dentry cache.
  58
  59 Red zoning and tracking may realign the slab.  We can just apply sanity checks
  60 to the dentry cache with
  61
  62         slub_debug=F,dentry_cache
  63
  64 In case you forgot to enable debugging on the kernel command line: It is
  65 possible to enable debugging manually when the kernel is up. Look at the
  66 contents of:
  67
  68 /sys/slab/<slab name>/
  69
  70 Look at the writable files. Writing 1 to them will enable the
  71 corresponding debug option. All options can be set on a slab that does
  72 not contain objects. If the slab already contains objects then sanity checks
  73 and tracing may only be enabled. The other options may cause the realignment
  74 of objects.
  75
  76 Careful with tracing: It may spew out lots of information and never stop if
  77 used on the wrong slab.
  78
  79 SLAB Merging
  80 ------------
  81
  82 If no debugging is specified then SLUB may merge similar slabs together
  83 in order to reduce overhead and increase cache hotness of objects.
  84 slabinfo -a displays which slabs were merged together.
  85
  86 Getting more performance
  87 ------------------------
  88
  89 To some degree SLUB's performance is limited by the need to take the
  90 list_lock once in a while to deal with partial slabs. That overhead is
  91 governed by the order of the allocation for each slab. The allocations
  92 can be influenced by kernel parameters:
  93
  94 slub_min_objects=x              (default 8)
  95 slub_min_order=x                (default 0)
  96 slub_max_order=x                (default 4)
  97
  98 slub_min_objects allows to specify how many objects must at least fit
  99 into one slab in order for the allocation order to be acceptable.
 100 In general slub will be able to perform this number of allocations
 101 on a slab without consulting centralized resources (list_lock) where
 102 contention may occur.
 103
 104 slub_min_order specifies a minim order of slabs. A similar effect like
 105 slub_min_objects.
 106
 107 slub_max_order specified the order at which slub_min_objects should no
 108 longer be checked. This is useful to avoid SLUB trying to generate
 109 super large order pages to fit slub_min_objects of a slab cache with
 110 large object sizes into one high order page.
 111
 112
 113 Christoph Lameter, <clameter@sgi.com>, April 10, 2007