1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
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.04"
.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 .
|
