summaryrefslogtreecommitdiffstats
path: root/man5/slabinfo.5
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-15 19:40:15 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-15 19:40:15 +0000
commit399644e47874bff147afb19c89228901ac39340e (patch)
tree1c4c0b733f4c16b5783b41bebb19194a9ef62ad1 /man5/slabinfo.5
parentInitial commit. (diff)
downloadmanpages-upstream/6.05.01.tar.xz
manpages-upstream/6.05.01.zip
Adding upstream version 6.05.01.upstream/6.05.01
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'man5/slabinfo.5')
-rw-r--r--man5/slabinfo.5220
1 files changed, 220 insertions, 0 deletions
diff --git a/man5/slabinfo.5 b/man5/slabinfo.5
new file mode 100644
index 0000000..e27ff80
--- /dev/null
+++ b/man5/slabinfo.5
@@ -0,0 +1,220 @@
+.\" Copyright (c) 2001 Andreas Dilger (adilger@turbolinux.com)
+.\" and Copyright (c) 2017 Michael Kerrisk <mtk.manpages@gmail.com>
+.\"
+.\" SPDX-License-Identifier: Linux-man-pages-copyleft
+.\"
+.TH slabinfo 5 2023-02-05 "Linux man-pages 6.05.01"
+.SH NAME
+slabinfo \- kernel slab allocator statistics
+.SH SYNOPSIS
+.nf
+.B cat /proc/slabinfo
+.fi
+.SH DESCRIPTION
+Frequently used objects in the Linux kernel
+(buffer heads, inodes, dentries, etc.)
+have their own cache.
+The file
+.I /proc/slabinfo
+gives statistics on these caches.
+The following (edited) output shows an example of the
+contents of this file:
+.PP
+.EX
+$ \fBsudo cat /proc/slabinfo\fP
+slabinfo \- version: 2.1
+# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> ...
+sigqueue 100 100 160 25 1 : tunables 0 0 0 : slabdata 4 4 0
+sighand_cache 355 405 2112 15 8 : tunables 0 0 0 : slabdata 27 27 0
+kmalloc\-8192 96 96 8192 4 8 : tunables 0 0 0 : slabdata 24 24 0
+\&...
+.EE
+.PP
+The first line of output includes a version number,
+which allows an application that is reading the file to handle changes
+in the file format.
+(See VERSIONS, below.)
+The next line lists the names of the columns in the remaining lines.
+.PP
+Each of the remaining lines displays information about a specified cache.
+Following the cache name,
+the output shown in each line shows three components for each cache:
+.IP \[bu] 3
+statistics
+.IP \[bu]
+tunables
+.IP \[bu]
+slabdata
+.PP
+The statistics are as follows:
+.TP
+.I active_objs
+The number of objects that are currently active (i.e., in use).
+.TP
+.I num_objs
+The total number of allocated objects
+(i.e., objects that are both in use and not in use).
+.TP
+.I objsize
+The size of objects in this slab, in bytes.
+.TP
+.I objperslab
+The number of objects stored in each slab.
+.TP
+.I pagesperslab
+The number of pages allocated for each slab.
+.PP
+The
+.I tunables
+entries in each line show tunable parameters for the corresponding cache.
+When using the default SLUB allocator, there are no tunables, the
+.I /proc/slabinfo
+file is not writable, and the value 0 is shown in these fields.
+When using the older SLAB allocator,
+the tunables for a particular cache can be set by writing
+lines of the following form to
+.IR /proc/slabinfo :
+.PP
+.in +4n
+.EX
+# \fBecho \[aq]name limit batchcount sharedfactor\[aq] > /proc/slabinfo\fP
+.EE
+.in
+.PP
+Here,
+.I name
+is the cache name, and
+.IR limit ,
+.IR batchcount ,
+and
+.I sharedfactor
+are integers defining new values for the corresponding tunables.
+The
+.I limit
+value should be a positive value,
+.I batchcount
+should be a positive value that is less than or equal to
+.IR limit ,
+and
+.I sharedfactor
+should be nonnegative.
+If any of the specified values is invalid,
+the cache settings are left unchanged.
+.PP
+The
+.I tunables
+entries in each line contain the following fields:
+.TP
+.I limit
+The maximum number of objects that will be cached.
+.\" https://lwn.net/Articles/56360/
+.\" This is the limit on the number of free objects that can be stored
+.\" in the per-CPU free list for this slab cache.
+.TP
+.I batchcount
+On SMP systems, this specifies the number of objects to transfer at one time
+when refilling the available object list.
+.\" https://lwn.net/Articles/56360/
+.\" On SMP systems, when we refill the available object list, instead
+.\" of doing one object at a time, we do batch-count objects at a time.
+.TP
+.I sharedfactor
+[To be documented]
+.\"
+.PP
+The
+.I slabdata
+entries in each line contain the following fields:
+.TP
+.I active_slabs
+The number of active slabs.
+.TP
+.I nums_slabs
+The total number of slabs.
+.TP
+.I sharedavail
+[To be documented]
+.PP
+Note that because of object alignment and slab cache overhead,
+objects are not normally packed tightly into pages.
+Pages with even one in-use object are considered in-use and cannot be
+freed.
+.PP
+Kernels configured with
+.B CONFIG_DEBUG_SLAB
+will also have additional statistics fields in each line,
+and the first line of the file will contain the string "(statistics)".
+The statistics field include : the high water mark of active
+objects; the number of times objects have been allocated;
+the number of times the cache has grown (new pages added
+to this cache); the number of times the cache has been
+reaped (unused pages removed from this cache); and the
+number of times there was an error allocating new pages
+to this cache.
+.\"
+.\" SMP systems will also have "(SMP)" in the first line of
+.\" output, and will have two additional columns for each slab,
+.\" reporting the slab allocation policy for the CPU-local
+.\" cache (to reduce the need for inter-CPU synchronization
+.\" when allocating objects from the cache).
+.\" The first column is the per-CPU limit: the maximum number of objects that
+.\" will be cached for each CPU.
+.\" The second column is the
+.\" batchcount: the maximum number of free objects in the
+.\" global cache that will be transferred to the per-CPU cache
+.\" if it is empty, or the number of objects to be returned
+.\" to the global cache if the per-CPU cache is full.
+.\"
+.\" If both slab cache statistics and SMP are defined, there
+.\" will be four additional columns, reporting the per-CPU
+.\" cache statistics.
+.\" The first two are the per-CPU cache
+.\" allocation hit and miss counts: the number of times an
+.\" object was or was not available in the per-CPU cache
+.\" for allocation.
+.\" The next two are the per-CPU cache free
+.\" hit and miss counts: the number of times a freed object
+.\" could or could not fit within the per-CPU cache limit,
+.\" before flushing objects to the global cache.
+.SH VERSIONS
+The
+.I /proc/slabinfo
+file first appeared in Linux 2.1.23.
+The file is versioned,
+and over time there have been a number of versions with different layouts:
+.TP
+1.0
+Present throughout the Linux 2.2.x kernel series.
+.TP
+1.1
+Present in the Linux 2.4.x kernel series.
+.\" First appeared in Linux 2.4.0-test3
+.TP
+1.2
+A format that was briefly present in the Linux 2.5 development series.
+.\" from Linux 2.5.45 to Linux 2.5.70
+.TP
+2.0
+Present in Linux 2.6.x kernels up to and including Linux 2.6.9.
+.\" First appeared in Linux 2.5.71
+.TP
+2.1
+The current format, which first appeared in Linux 2.6.10.
+.SH NOTES
+Only root can read and (if the kernel was configured with
+.BR CONFIG_SLAB )
+write the
+.I /proc/slabinfo
+file.
+.PP
+The total amount of memory allocated to the SLAB/SLUB cache is shown in the
+.I Slab
+field of
+.IR /proc/meminfo .
+.SH SEE ALSO
+.BR slabtop (1)
+.PP
+The kernel source file
+.I Documentation/vm/slub.txt
+and
+.IR tools/vm/slabinfo.c .