]>
Commit | Line | Data |
---|---|---|
35243421 CL |
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 |