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