| Parent Directory|
Linux Kernel Objects
The Kernel Objects - Overruled !!! :)
As the kernel does its work, it has to keep track of things.
Many of the these things are objects of one sort or another.
As this is a very, very dynamic area of operations, the kernel
creates and disposes of objects using the object cache.
The structure (struct) of an object can be seen here:
Access to these objects is via lists (actualy, doubly-linked lists):
And to speed things up further, there are lists of lists.
And lists of lists of lists. And lists of... (well, you get the idea.)
As you can imagine, if the kernel has to do lots of object creation
or distruction, just keeping up with that at periods of excessive activity
may prevent the OS from doing anything else. And in fact this happens;
its called "resource starvation" of one form or another.
To help avoid this there are some kernel tunables you should know about.
Object Caches - Overview
There are a couple different ways that objects can be cached:
SLOB - Simple list of Objects
This is an older, slower format for allocating kernel objects.
It is memory efficient, and thus has a home on mobile devices.
SLAB - The default method. Objects are allocated on SLABs.
This is fast, but can use a large amount of memory.
SLUB - Newer method than SLAB. By Christoph Lameter - SGI.
Slightly slower than SLAB, but uses *so* much less space.
Object Caches - Details
Objects are allocated in memory. Memory (RAM) is kept in pages. Rather than
dynamically allocating objects from pages when they are needed and destroying
them when they are not, SLAB dictates that objects be created before they are
needed and recycled once they are finished.
Objects are created on SLABs, and SLABs are created on pages. Once one slab
has no free objects the next slab is uses. Once all the slabs are used more
are allocated. Together, the group of pages containing slabs of one kind of
object are called a cache. A cache contains a ready-to-use objects of a
The kernel has many different caches. They can be viewed with:
1. slabtop (run `slabtop --wtf` to see the help/usage screen)
2. `cat /proc/slabinfo`
Looking at this file over time (once a day for a week) can reveal
patterns - such as a memory leak and where it is.
> From Linus:
> /proc/slabinfo was (and is) totally pointless for "trying to eyeball
> what's going on". The output is totally unreadable, and useless. You end
> up with exactly the same script as above, except it reads as
> cat /proc/slabinfo | (read headerline
> while read name active num objsize objsperslab pagesperslab
> realsize=$(( nul * objsize ))
> size=$(( active * objsize ))
> .. exact same rest of loop ..
> done | sort -n | ..
You can get the total size of the slab from `grep -i slab /proc/meminfo`.
SGI was the driver for SLUB. Noticing that kernel memory could be as much as
one GB, in a 64-blade rack this amounted to 64 GB of RAM that was unavailable
for application. Now imagine 20 racks.
The code was merged into the 2.6.22 kernel as an alternate form of kernel
Again from Linus, a comment that /sys/slub could be more easily
parsed than /proc/slabinfo, with something like:
for i in *
truesize=$(( $slabs<<($order+12) ))
size=$(( $object_size*$objects ))
percent=$(( $truesize/100 ))
if [ $percent -gt 0 ]; then
percent=$(( $size / $percent ))
mb=$(( $size >> 10 ))
printf "%10d MB %3d %s\n" $mb $percent $i
done | sort -n | tail
For details on SLUB, see: http://lwn.net/Articles/229984/
From the 2.6.22 diff file:
+ default y
+ bool "Enable SLUB debugging support" if EMBEDDED
+ depends on SLUB
+ SLUB has extensive debug support features. Disabling these can
+ result in significant savings in code size. This also disables
+ SLUB sysfs support. /sys/slab will not exist and there will be
+ no support for cache validation etc.
+ prompt "Choose SLAB allocator"
+ default SLAB
+ This option allows to select a slab allocator.
+ bool "SLAB"
+ The regular slab allocator that is established and known to work
+ well in all environments. It organizes cache hot objects in
+ per cpu and per node queues. SLAB is the default choice for
+ a slab allocator.
+ bool "SLUB (Unqueued Allocator)"
+ SLUB is a slab allocator that minimizes cache line usage
+ instead of managing queues of cached objects (SLAB approach).
+ Per cpu caching is realized using slabs of objects instead
+ of queues of objects. SLUB can use memory efficiently
+ and has enhanced diagnostics.
+ depends on EMBEDDED && !SPARSEMEM
+ bool "SLOB (Simple Allocator)"
+ SLOB replaces the SLAB allocator with a drastically simpler
+ allocator. SLOB is more space efficient than SLAB but does not
+ scale well (single lock for all operations) and is also highly
+ susceptible to fragmentation. SLUB can accomplish a higher object
+ density. It is usually better to use SLUB instead of SLOB.
For more, see:
This site contains many of my notes from research into different aspects of
the Linux kernel as well as some of the software provided by GNU and others.
Thouugh these notes are not fully comprehensive or even completetly accurate,
they are part of my on-going attempt to better understand this complex field.
And, they are your to use.
Should you wish to report any errors or suggestions, please let me know.
Should you wish to make a donation for anything you may have learned here,
please direct that donation to the
with my sincere thanks.
The code for this site, which is just a few CGI scripts, may be found on GitHub
For both data encryption and password protection, try Personal Data Security
"We left all that stuff out. If there's an error, we have this
routine called 'panic', and when its called, the machine crashes,
and you holler down the hall, 'Hey, reboot it.'"
- Dennis Ritchie on Unix (vs Multics)