slabinfo(5)

💖 slabinfo — bestie's guide to kernel slab allocator statistics ✨

okay so like, slabinfo is the manual page (it's in section 5, the file formats girlies) all about /proc/slabinfo — which is literally the receipt for everything the kernel's slab allocator is doing. no cap. let's get into it 🫶

---

✨ SYNOPSIS ✨

cat /proc/slabinfo

that's it. that's the whole vibe. 💅

---

🌸 DESCRIPTION 🌸

so the tea is: all the objects the Linux kernel uses constantly — buffer heads, inodes, dentries, etc. — get their own little cache to live in. and the file /proc/slabinfo is where you go to read the statistics on all those caches. it's giving open-book exam 👑

here's a little (edited) peek at what's inside:

$ sudo cat /proc/slabinfo;
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
...

first line of output = the version number, so an application reading the file can stay chill when the format changes. (scroll down to VERSIONS if you're nosy 👀)

second line = the column names for everything below it.

every line after that = one specific cache, and after the cache name you get three components:

• statistics
• tunables
• slabdata

📊 the statistics, explained

• active_objs — how many objects are currently active, aka actually in use. the main characters 🎀
• num_objs — the total number of allocated objects, meaning the in-use ones plus the not-in-use ones. everyone invited to the party.
• objsize — size of the objects in this slab, in bytes.
• objperslab — how many objects get stored in each slab.
• pagesperslab — how many pages get allocated for each slab.

🎛️ the tunables, explained

these show the tunable parameters for that cache. here's the important part bestie:

when you're on the default SLUB allocator, there are no tunables, the /proc/slabinfo file is not writable, and these fields just show the value 0. that's normal, don't panic. 🧚

when you're on the older SLAB allocator, you can set the tunables for a particular cache by writing lines shaped like this into /proc/slabinfo:

# echo 'name limit batchcount sharedfactor' > /proc/slabinfo;

breakdown: name is the cache name, and limit, batchcount, and sharedfactor are integers defining the new values for the corresponding tunables. the rules, fr fr:

• limit should be a positive value
• batchcount should be a positive value that is less than or equal to limit
• sharedfactor should be nonnegative

and if any of the specified values is invalid? the cache settings are just left unchanged. no harm, no foul. 🙈

the tunables fields in each line are:

• limit — the maximum number of objects that will be cached.
• batchcount — on SMP systems, this specifies the number of objects to transfer at one time when refilling the available object list.
• sharedfactor — [To be documented] 💀 (yes really, that's what it says, i don't make the rules)

🧱 the slabdata, explained

• active_slabs — the number of active slabs.
• nums_slabs — the total number of slabs.
• sharedavail — [To be documented] (again. iconic of them honestly)

---

heads up: because of object alignment and slab cache overhead, objects are not normally packed tightly into pages. and pages with even one in-use object count as in-use and cannot be freed. so like, a page with one lonely little guy in it is still fully committed. 😭

---

also! kernels configured with CONFIG_DEBUG_SLAB get extra statistics fields in each line, and the first line of the file will contain the string "(statistics)". those extra statistics 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)
• the number of times there was an error allocating new pages to this cache

very detective of them 🔍

---

🦋 VERSIONS 🦋

/proc/slabinfo first appeared in Linux 2.1.23. it's versioned, and over time there have been a bunch of versions with different layouts — a whole glow-up timeline:

1. 1.0 — present throughout the Linux 2.2.x kernel series.
2. 1.1 — present in the Linux 2.4.x kernel series.
3. 1.2 — a format that was briefly present in the Linux 2.5 development series.
4. 2.0 — present in Linux 2.6.x kernels up to and including Linux 2.6.9.
5. 2.1 — the current format, which first appeared in Linux 2.6.10. 👑

---

💜 NOTES 💜

• only root can read — and, if the kernel was configured with CONFIG_SLAB, write — the /proc/slabinfo file. sorry bestie, it's a VIP section.
• the total amount of memory allocated to the SLAB/SLUB cache is shown in the Slab field of /proc/meminfo.

---

🌈 SEE ALSO 🌈

• slabtop(1)
• the kernel source file Documentation/mm/slab.rst and tools/mm/slabinfo.c

---

and that's the whole page, bestie!! you ate that. 🍓✨ this was written by the Linux man-pages 6.20 girlies, dated 2026-02-08 — mwah, slay, periodt. 💅💖