Everything Penguin

Focusing on Linux-based Operating Systems
htDig Search:

Operating Systems
  • /pub/OS/Linux

  • Storage
  • File Systems
  • HPC
  • /pub/Storage

  • Networking
  • /pub/Networking

  • Network Services
  • /pub/NetworkServices

  • Security
  • /pub/Security
  • Keytool/OpenSSL

  • Clustering
  • HA
  • DRM

  • Development
  • Design
  • C/C++
  • Java
  • Perl
  • Python
  • Shell
  • Web / J2EE

  • Not Linux ?
  • BSD
  • HP-UX
  • Mac
  • Solaris
  • VM
  • Windows
  • /pub/OS

  • Other
  • /pub
  • /pub/3rdParty
  •  Parent Directory

    Linux Kernel Objects
    Brett Lee
    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
    certain type.
    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
    >               rest
    >               do
    >                       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
    memory management. 
            Again from Linus, a comment that /sys/slub could be more easily
            parsed than /proc/slabinfo, with something like:
            for i in *
                order=$(cat "$i/order")
                slabs=$(cat "$i/slabs")
                object_size=$(cat "$i/object_size")
                objects=$(cat "$i/objects")
                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:
    +config SLUB_DEBUG
    +   default y
    +   bool "Enable SLUB debugging support" if EMBEDDED
    +   depends on SLUB
    +   help
    +     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
    +   help
    +      This option allows to select a slab allocator.
    +config SLAB
    +   bool "SLAB"
    +   help
    +     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.
    +config SLUB
    +   bool "SLUB (Unqueued Allocator)"
    +   help
    +      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.
    +config SLOB
    +   depends on EMBEDDED && !SPARSEMEM
    +   bool "SLOB (Simple Allocator)"
    +   help
    +      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:

    Other Sites

  • FAQ's
  • IETF
  • RFC Sourcebook

  • Linux
  • Linux - Intro
  • Linux Kernel
  • Linux Kernel (LKML)
  • Bash - Intro
  • Bash - Advanced
  • Command Line
  • System Administration
  • Network Administration
  • Man Pages (& more)
  • More Guides
  • Red Hat Manuals
  • HOWTO's

  • Reference/Tutorials
  • C++ @ cppreference
  • C++ @ cplusplus
  • CSS @ echoecho
  • DNS @ Zytrax
  • HTML @ W3 Schools
  • Java @ Sun
  • LDAP @ Zytrax
  • Linux @ YoLinux
  • MySQL
  • NetFilter
  • Network Protocols
  • OpenLDAP
  • Quagga
  • Samba
  • Unix Programming

  • 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 ASPCA, with my sincere thanks.

    Brett Lee
    Everything Penguin

    The code for this site, which is just a few CGI scripts, may be found on GitHub (https://github.com/userbrett/cgindex).

    For both data encryption and password protection, try Personal Data Security (https://www.trustpds.com).

    "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)

    [ Powered by Red Hat Linux ] [ Powered by Apache Server] [ Powered by MySQL ]

    [ Statistics by AWStats ]