462 lines · plain
1==========================2Short users guide for SLUB3==========================4 5The basic philosophy of SLUB is very different from SLAB. SLAB6requires rebuilding the kernel to activate debug options for all7slab caches. SLUB always includes full debugging but it is off by default.8SLUB can enable debugging only for selected slabs in order to avoid9an impact on overall system performance which may make a bug more10difficult to find.11 12In order to switch debugging on one can add an option ``slab_debug``13to the kernel command line. That will enable full debugging for14all slabs.15 16Typically one would then use the ``slabinfo`` command to get statistical17data and perform operation on the slabs. By default ``slabinfo`` only lists18slabs that have data in them. See "slabinfo -h" for more options when19running the command. ``slabinfo`` can be compiled with20::21 22 gcc -o slabinfo tools/mm/slabinfo.c23 24Some of the modes of operation of ``slabinfo`` require that slub debugging25be enabled on the command line. F.e. no tracking information will be26available without debugging on and validation can only partially27be performed if debugging was not switched on.28 29Some more sophisticated uses of slab_debug:30-------------------------------------------31 32Parameters may be given to ``slab_debug``. If none is specified then full33debugging is enabled. Format:34 35slab_debug=<Debug-Options>36 Enable options for all slabs37 38slab_debug=<Debug-Options>,<slab name1>,<slab name2>,...39 Enable options only for select slabs (no spaces40 after a comma)41 42Multiple blocks of options for all slabs or selected slabs can be given, with43blocks of options delimited by ';'. The last of "all slabs" blocks is applied44to all slabs except those that match one of the "select slabs" block. Options45of the first "select slabs" blocks that matches the slab's name are applied.46 47Possible debug options are::48 49 F Sanity checks on (enables SLAB_DEBUG_CONSISTENCY_CHECKS50 Sorry SLAB legacy issues)51 Z Red zoning52 P Poisoning (object and padding)53 U User tracking (free and alloc)54 T Trace (please only use on single slabs)55 A Enable failslab filter mark for the cache56 O Switch debugging off for caches that would have57 caused higher minimum slab orders58 - Switch all debugging off (useful if the kernel is59 configured with CONFIG_SLUB_DEBUG_ON)60 61F.e. in order to boot just with sanity checks and red zoning one would specify::62 63 slab_debug=FZ64 65Trying to find an issue in the dentry cache? Try::66 67 slab_debug=,dentry68 69to only enable debugging on the dentry cache. You may use an asterisk at the70end of the slab name, in order to cover all slabs with the same prefix. For71example, here's how you can poison the dentry cache as well as all kmalloc72slabs::73 74 slab_debug=P,kmalloc-*,dentry75 76Red zoning and tracking may realign the slab. We can just apply sanity checks77to the dentry cache with::78 79 slab_debug=F,dentry80 81Debugging options may require the minimum possible slab order to increase as82a result of storing the metadata (for example, caches with PAGE_SIZE object83sizes). This has a higher likelihood of resulting in slab allocation errors84in low memory situations or if there's high fragmentation of memory. To85switch off debugging for such caches by default, use::86 87 slab_debug=O88 89You can apply different options to different list of slab names, using blocks90of options. This will enable red zoning for dentry and user tracking for91kmalloc. All other slabs will not get any debugging enabled::92 93 slab_debug=Z,dentry;U,kmalloc-*94 95You can also enable options (e.g. sanity checks and poisoning) for all caches96except some that are deemed too performance critical and don't need to be97debugged by specifying global debug options followed by a list of slab names98with "-" as options::99 100 slab_debug=FZ;-,zs_handle,zspage101 102The state of each debug option for a slab can be found in the respective files103under::104 105 /sys/kernel/slab/<slab name>/106 107If the file contains 1, the option is enabled, 0 means disabled. The debug108options from the ``slab_debug`` parameter translate to the following files::109 110 F sanity_checks111 Z red_zone112 P poison113 U store_user114 T trace115 A failslab116 117failslab file is writable, so writing 1 or 0 will enable or disable118the option at runtime. Write returns -EINVAL if cache is an alias.119Careful with tracing: It may spew out lots of information and never stop if120used on the wrong slab.121 122Slab merging123============124 125If no debug options are specified then SLUB may merge similar slabs together126in order to reduce overhead and increase cache hotness of objects.127``slabinfo -a`` displays which slabs were merged together.128 129Slab validation130===============131 132SLUB can validate all object if the kernel was booted with slab_debug. In133order to do so you must have the ``slabinfo`` tool. Then you can do134::135 136 slabinfo -v137 138which will test all objects. Output will be generated to the syslog.139 140This also works in a more limited way if boot was without slab debug.141In that case ``slabinfo -v`` simply tests all reachable objects. Usually142these are in the cpu slabs and the partial slabs. Full slabs are not143tracked by SLUB in a non debug situation.144 145Getting more performance146========================147 148To some degree SLUB's performance is limited by the need to take the149list_lock once in a while to deal with partial slabs. That overhead is150governed by the order of the allocation for each slab. The allocations151can be influenced by kernel parameters:152 153.. slab_min_objects=x (default: automatically scaled by number of cpus)154.. slab_min_order=x (default 0)155.. slab_max_order=x (default 3 (PAGE_ALLOC_COSTLY_ORDER))156 157``slab_min_objects``158 allows to specify how many objects must at least fit into one159 slab in order for the allocation order to be acceptable. In160 general slub will be able to perform this number of161 allocations on a slab without consulting centralized resources162 (list_lock) where contention may occur.163 164``slab_min_order``165 specifies a minimum order of slabs. A similar effect like166 ``slab_min_objects``.167 168``slab_max_order``169 specified the order at which ``slab_min_objects`` should no170 longer be checked. This is useful to avoid SLUB trying to171 generate super large order pages to fit ``slab_min_objects``172 of a slab cache with large object sizes into one high order173 page. Setting command line parameter174 ``debug_guardpage_minorder=N`` (N > 0), forces setting175 ``slab_max_order`` to 0, what cause minimum possible order of176 slabs allocation.177 178SLUB Debug output179=================180 181Here is a sample of slub debug output::182 183 ====================================================================184 BUG kmalloc-8: Right Redzone overwritten185 --------------------------------------------------------------------186 187 INFO: 0xc90f6d28-0xc90f6d2b. First byte 0x00 instead of 0xcc188 INFO: Slab 0xc528c530 flags=0x400000c3 inuse=61 fp=0xc90f6d58189 INFO: Object 0xc90f6d20 @offset=3360 fp=0xc90f6d58190 INFO: Allocated in get_modalias+0x61/0xf5 age=53 cpu=1 pid=554191 192 Bytes b4 (0xc90f6d10): 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ193 Object (0xc90f6d20): 31 30 31 39 2e 30 30 35 1019.005194 Redzone (0xc90f6d28): 00 cc cc cc .195 Padding (0xc90f6d50): 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ196 197 [<c010523d>] dump_trace+0x63/0x1eb198 [<c01053df>] show_trace_log_lvl+0x1a/0x2f199 [<c010601d>] show_trace+0x12/0x14200 [<c0106035>] dump_stack+0x16/0x18201 [<c017e0fa>] object_err+0x143/0x14b202 [<c017e2cc>] check_object+0x66/0x234203 [<c017eb43>] __slab_free+0x239/0x384204 [<c017f446>] kfree+0xa6/0xc6205 [<c02e2335>] get_modalias+0xb9/0xf5206 [<c02e23b7>] dmi_dev_uevent+0x27/0x3c207 [<c027866a>] dev_uevent+0x1ad/0x1da208 [<c0205024>] kobject_uevent_env+0x20a/0x45b209 [<c020527f>] kobject_uevent+0xa/0xf210 [<c02779f1>] store_uevent+0x4f/0x58211 [<c027758e>] dev_attr_store+0x29/0x2f212 [<c01bec4f>] sysfs_write_file+0x16e/0x19c213 [<c0183ba7>] vfs_write+0xd1/0x15a214 [<c01841d7>] sys_write+0x3d/0x72215 [<c0104112>] sysenter_past_esp+0x5f/0x99216 [<b7f7b410>] 0xb7f7b410217 =======================218 219 FIX kmalloc-8: Restoring Redzone 0xc90f6d28-0xc90f6d2b=0xcc220 221If SLUB encounters a corrupted object (full detection requires the kernel222to be booted with slab_debug) then the following output will be dumped223into the syslog:224 2251. Description of the problem encountered226 227 This will be a message in the system log starting with::228 229 ===============================================230 BUG <slab cache affected>: <What went wrong>231 -----------------------------------------------232 233 INFO: <corruption start>-<corruption_end> <more info>234 INFO: Slab <address> <slab information>235 INFO: Object <address> <object information>236 INFO: Allocated in <kernel function> age=<jiffies since alloc> cpu=<allocated by237 cpu> pid=<pid of the process>238 INFO: Freed in <kernel function> age=<jiffies since free> cpu=<freed by cpu>239 pid=<pid of the process>240 241 (Object allocation / free information is only available if SLAB_STORE_USER is242 set for the slab. slab_debug sets that option)243 2442. The object contents if an object was involved.245 246 Various types of lines can follow the BUG SLUB line:247 248 Bytes b4 <address> : <bytes>249 Shows a few bytes before the object where the problem was detected.250 Can be useful if the corruption does not stop with the start of the251 object.252 253 Object <address> : <bytes>254 The bytes of the object. If the object is inactive then the bytes255 typically contain poison values. Any non-poison value shows a256 corruption by a write after free.257 258 Redzone <address> : <bytes>259 The Redzone following the object. The Redzone is used to detect260 writes after the object. All bytes should always have the same261 value. If there is any deviation then it is due to a write after262 the object boundary.263 264 (Redzone information is only available if SLAB_RED_ZONE is set.265 slab_debug sets that option)266 267 Padding <address> : <bytes>268 Unused data to fill up the space in order to get the next object269 properly aligned. In the debug case we make sure that there are270 at least 4 bytes of padding. This allows the detection of writes271 before the object.272 2733. A stackdump274 275 The stackdump describes the location where the error was detected. The cause276 of the corruption is may be more likely found by looking at the function that277 allocated or freed the object.278 2794. Report on how the problem was dealt with in order to ensure the continued280 operation of the system.281 282 These are messages in the system log beginning with::283 284 FIX <slab cache affected>: <corrective action taken>285 286 In the above sample SLUB found that the Redzone of an active object has287 been overwritten. Here a string of 8 characters was written into a slab that288 has the length of 8 characters. However, a 8 character string needs a289 terminating 0. That zero has overwritten the first byte of the Redzone field.290 After reporting the details of the issue encountered the FIX SLUB message291 tells us that SLUB has restored the Redzone to its proper value and then292 system operations continue.293 294Emergency operations295====================296 297Minimal debugging (sanity checks alone) can be enabled by booting with::298 299 slab_debug=F300 301This will be generally be enough to enable the resiliency features of slub302which will keep the system running even if a bad kernel component will303keep corrupting objects. This may be important for production systems.304Performance will be impacted by the sanity checks and there will be a305continual stream of error messages to the syslog but no additional memory306will be used (unlike full debugging).307 308No guarantees. The kernel component still needs to be fixed. Performance309may be optimized further by locating the slab that experiences corruption310and enabling debugging only for that cache311 312I.e.::313 314 slab_debug=F,dentry315 316If the corruption occurs by writing after the end of the object then it317may be advisable to enable a Redzone to avoid corrupting the beginning318of other objects::319 320 slab_debug=FZ,dentry321 322Extended slabinfo mode and plotting323===================================324 325The ``slabinfo`` tool has a special 'extended' ('-X') mode that includes:326 - Slabcache Totals327 - Slabs sorted by size (up to -N <num> slabs, default 1)328 - Slabs sorted by loss (up to -N <num> slabs, default 1)329 330Additionally, in this mode ``slabinfo`` does not dynamically scale331sizes (G/M/K) and reports everything in bytes (this functionality is332also available to other slabinfo modes via '-B' option) which makes333reporting more precise and accurate. Moreover, in some sense the `-X'334mode also simplifies the analysis of slabs' behaviour, because its335output can be plotted using the ``slabinfo-gnuplot.sh`` script. So it336pushes the analysis from looking through the numbers (tons of numbers)337to something easier -- visual analysis.338 339To generate plots:340 341a) collect slabinfo extended records, for example::342 343 while [ 1 ]; do slabinfo -X >> FOO_STATS; sleep 1; done344 345b) pass stats file(-s) to ``slabinfo-gnuplot.sh`` script::346 347 slabinfo-gnuplot.sh FOO_STATS [FOO_STATS2 .. FOO_STATSN]348 349 The ``slabinfo-gnuplot.sh`` script will pre-processes the collected records350 and generates 3 png files (and 3 pre-processing cache files) per STATS351 file:352 - Slabcache Totals: FOO_STATS-totals.png353 - Slabs sorted by size: FOO_STATS-slabs-by-size.png354 - Slabs sorted by loss: FOO_STATS-slabs-by-loss.png355 356Another use case, when ``slabinfo-gnuplot.sh`` can be useful, is when you357need to compare slabs' behaviour "prior to" and "after" some code358modification. To help you out there, ``slabinfo-gnuplot.sh`` script359can 'merge' the `Slabcache Totals` sections from different360measurements. To visually compare N plots:361 362a) Collect as many STATS1, STATS2, .. STATSN files as you need::363 364 while [ 1 ]; do slabinfo -X >> STATS<X>; sleep 1; done365 366b) Pre-process those STATS files::367 368 slabinfo-gnuplot.sh STATS1 STATS2 .. STATSN369 370c) Execute ``slabinfo-gnuplot.sh`` in '-t' mode, passing all of the371 generated pre-processed \*-totals::372 373 slabinfo-gnuplot.sh -t STATS1-totals STATS2-totals .. STATSN-totals374 375 This will produce a single plot (png file).376 377 Plots, expectedly, can be large so some fluctuations or small spikes378 can go unnoticed. To deal with that, ``slabinfo-gnuplot.sh`` has two379 options to 'zoom-in'/'zoom-out':380 381 a) ``-s %d,%d`` -- overwrites the default image width and height382 b) ``-r %d,%d`` -- specifies a range of samples to use (for example,383 in ``slabinfo -X >> FOO_STATS; sleep 1;`` case, using a ``-r384 40,60`` range will plot only samples collected between 40th and385 60th seconds).386 387 388DebugFS files for SLUB389======================390 391For more information about current state of SLUB caches with the user tracking392debug option enabled, debugfs files are available, typically under393/sys/kernel/debug/slab/<cache>/ (created only for caches with enabled user394tracking). There are 2 types of these files with the following debug395information:396 3971. alloc_traces::398 399 Prints information about unique allocation traces of the currently400 allocated objects. The output is sorted by frequency of each trace.401 402 Information in the output:403 Number of objects, allocating function, possible memory wastage of404 kmalloc objects(total/per-object), minimal/average/maximal jiffies405 since alloc, pid range of the allocating processes, cpu mask of406 allocating cpus, numa node mask of origins of memory, and stack trace.407 408 Example:::409 410 338 pci_alloc_dev+0x2c/0xa0 waste=521872/1544 age=290837/291891/293509 pid=1 cpus=106 nodes=0-1411 __kmem_cache_alloc_node+0x11f/0x4e0412 kmalloc_trace+0x26/0xa0413 pci_alloc_dev+0x2c/0xa0414 pci_scan_single_device+0xd2/0x150415 pci_scan_slot+0xf7/0x2d0416 pci_scan_child_bus_extend+0x4e/0x360417 acpi_pci_root_create+0x32e/0x3b0418 pci_acpi_scan_root+0x2b9/0x2d0419 acpi_pci_root_add.cold.11+0x110/0xb0a420 acpi_bus_attach+0x262/0x3f0421 device_for_each_child+0xb7/0x110422 acpi_dev_for_each_child+0x77/0xa0423 acpi_bus_attach+0x108/0x3f0424 device_for_each_child+0xb7/0x110425 acpi_dev_for_each_child+0x77/0xa0426 acpi_bus_attach+0x108/0x3f0427 4282. free_traces::429 430 Prints information about unique freeing traces of the currently allocated431 objects. The freeing traces thus come from the previous life-cycle of the432 objects and are reported as not available for objects allocated for the first433 time. The output is sorted by frequency of each trace.434 435 Information in the output:436 Number of objects, freeing function, minimal/average/maximal jiffies since free,437 pid range of the freeing processes, cpu mask of freeing cpus, and stack trace.438 439 Example:::440 441 1980 <not-available> age=4294912290 pid=0 cpus=0442 51 acpi_ut_update_ref_count+0x6a6/0x782 age=236886/237027/237772 pid=1 cpus=1443 kfree+0x2db/0x420444 acpi_ut_update_ref_count+0x6a6/0x782445 acpi_ut_update_object_reference+0x1ad/0x234446 acpi_ut_remove_reference+0x7d/0x84447 acpi_rs_get_prt_method_data+0x97/0xd6448 acpi_get_irq_routing_table+0x82/0xc4449 acpi_pci_irq_find_prt_entry+0x8e/0x2e0450 acpi_pci_irq_lookup+0x3a/0x1e0451 acpi_pci_irq_enable+0x77/0x240452 pcibios_enable_device+0x39/0x40453 do_pci_enable_device.part.0+0x5d/0xe0454 pci_enable_device_flags+0xfc/0x120455 pci_enable_device+0x13/0x20456 virtio_pci_probe+0x9e/0x170457 local_pci_probe+0x48/0x80458 pci_device_probe+0x105/0x1c0459 460Christoph Lameter, May 30, 2007461Sergey Senozhatsky, October 23, 2015462