Here is some information about /proc/slabinf (for the 2.4 kernel), from Doug Ledford in 2003. See

+

Here is some information about /proc/slabinfo. Some of this information was obtained from a writeup done by

−

below for the source.

+

Doug Ledford in 2003, for the 2.4.x kernel. See below for the source.

Here is a description of some of the fields in <tt>/proc/slabinfo</tt>

Here is a description of some of the fields in <tt>/proc/slabinfo</tt>

−

active_objs: after creating a slab cache, you allocate your objects

+

;active_objs

−

out of that slab cache. This is the count of objects you currently have

+

:After creating a slab cache, you allocate your objects out of that slab cache. This is the count of objects you currently have allocated out of the cache.

−

allocated out of the cache.

+

−

num_objs: this is the current total number of objects in the

+

;num_objs

−

cache.

+

:This is the current total number of objects in the cache.

−

objsize: this is the size of each allocated object. There is

+

;objsize:

−

overhead to maintaining the cache, so with a 512byte object and a

+

:This is the size of each allocated object. There is overhead to maintaining the cache, so with a 512byte object and a 4096-byte page size, you could fit 7 objects in a single page and you would waste 512-slab_overhead bytes per allocation. Slab overhead varies with object size (smaller objects have more objects per allocation and require more overhead to track used vs. unused objects).

−

4096byte page size, you could fit 7 objects in a single page and you

+

−

would waste 512-slab_overhead bytes per allocation. Slab overhead

+

−

varies with object size (smaller objects have more objects per

+

−

allocation and require more overhead to track used vs. unused objects).

+

−

ojbsperslab: This is how many objects can be put into each slab. To find

+

;ojbsperslab

−

the amount of wasted bytes per slab, multiply the objsize by objperslab, and

+

:This is how many objects can be put into each slab. To find the amount of wasted bytes per slab, multiply the objsize by objperslab, and subtract this from pagesperslab times the pagesize (often 4096).

−

subtract this from pagesperslab times the pagesize (often 4096).

+

−

pagesperslab: This is the size of each slab in units of memory

+

;pagesperslab

−

pages. Page size is architecture specific, but the most common size is

+

:This is the size of each slab in units of memory pages. Page size is architecture specific, but the most common size is 4k (4096 bytes). Some architectures have an 8k page size, and ia64 can do a 16k page size. Each slab for the cache is pagesperslab * arch_page_size bytes at a time, and total memory used by this particular slab cache is num_slabs * pagesperslab * arch_page_size.

−

4k (4096 bytes). Some architectures have an 8k page size, and ia64 can do a 16k

+

−

page size. Each slab for the cache is pagesperslab * arch_page_size

+

−

bytes at a time, and total memory used by this particular slab cache is

+

−

total_slab_allocs * pagesperslab * arch_page_size.

+

−

active-slabs: This is the number of slabs that have at least

+

;active_slabs

−

one object in use.

+

:This is the number of slabs that have at least one object in use.

−

total-slab-allocs: The total number of allocations in the current slab

+

;num_slabs

−

cache.

+

:This is the number of slabs currently allocated for the given cache.

−

alloc-size:

−

The last 2 items are SMP specific and don't show up at all on UP

+

On SMP machines, the slab cache will keep a per CPU cache of

−

kernels. On SMP machines, the slab cache will keep a per CPU cache of

+

objects so that an object freed on CPU0 will be reused on CPU0 instead

objects so that an object freed on CPU0 will be reused on CPU0 instead

of CPU1 if possible. This improves cache performance on SMP systems

of CPU1 if possible. This improves cache performance on SMP systems

greatly.

greatly.

−

limit: This is the limit on the number of free objects that can be

+

;limit

−

stored in the per-CPU free list for this slab cache.

+

:This is the limit on the number of free objects that can be stored in the per-CPU free list for this slab cache.

−

batch-count: On SMP systems, when we refill the available object list,

+

;batch-count

−

instead of doing one object at a time, we do batch-count objects at a

+

: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.

<tt>Documentation/vm/slabinfo.c</tt>. This program can be used for debugging

<tt>Documentation/vm/slabinfo.c</tt>. This program can be used for debugging

the slub allocator, not the slab allocator.

the slub allocator, not the slab allocator.

+

+

[[Category:Kernel]]

Latest revision as of 22:32, 27 October 2011

Here is some information on the slab allocator in Linux.

(As I write this (8/2007), a new allocator "slub" has been submitted for inclusion
in mainline. It remains to be seen if this means that the slab allocator will be removed.)

You can get a lot of information about the status of the slab allocator by
examining the data in /proc/slabinfo.

The slab allocator is a system of allocating memory that is optimized for
the allocation and freeing of same-sized memory objects. The slab allocator
organizes the memory into caches, slabs and objects. A cache consists of multiple
slabs, and each slab is a contiguous region of memory containing objects of
all the same size.

When a cache is created, the creator specifies the object size and a name
for the cache, as well as some flags. When an object is allocated, if there are no free
objects in any slabs, a new slab is allocated. For small objects, a slab is a single page of memory. For example, on a system with 4096-byte pages, a cache of objects that are 160 bytes
each would consist of slabs containing 24 objects per slab. Subsequent calls to allocate
objects of the same size are quick, because the page has already been allocated for the object. Calls to free an object are also quick. If the system gets into a low memory condition, slabs with no allocated objects can be freed. Fragmentation is reduced (hopefully) because similar sized
objects are grouped together.

Documentation of /proc/slabinfo fields

Here is some information about /proc/slabinfo. Some of this information was obtained from a writeup done by
Doug Ledford in 2003, for the 2.4.x kernel. See below for the source.

Here is a description of some of the fields in /proc/slabinfo

active_objs

After creating a slab cache, you allocate your objects out of that slab cache. This is the count of objects you currently have allocated out of the cache.

num_objs

This is the current total number of objects in the cache.

objsize

This is the size of each allocated object. There is overhead to maintaining the cache, so with a 512byte object and a 4096-byte page size, you could fit 7 objects in a single page and you would waste 512-slab_overhead bytes per allocation. Slab overhead varies with object size (smaller objects have more objects per allocation and require more overhead to track used vs. unused objects).

ojbsperslab

This is how many objects can be put into each slab. To find the amount of wasted bytes per slab, multiply the objsize by objperslab, and subtract this from pagesperslab times the pagesize (often 4096).

pagesperslab

This is the size of each slab in units of memory pages. Page size is architecture specific, but the most common size is 4k (4096 bytes). Some architectures have an 8k page size, and ia64 can do a 16k page size. Each slab for the cache is pagesperslab * arch_page_size bytes at a time, and total memory used by this particular slab cache is num_slabs * pagesperslab * arch_page_size.

active_slabs

This is the number of slabs that have at least one object in use.

num_slabs

This is the number of slabs currently allocated for the given cache.

On SMP machines, the slab cache will keep a per CPU cache of
objects so that an object freed on CPU0 will be reused on CPU0 instead
of CPU1 if possible. This improves cache performance on SMP systems
greatly.

limit

This is the limit on the number of free objects that can be stored in the per-CPU free list for this slab cache.

batch-count

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.

Note that is CONFIG_SLAB_DEBUG is enabled, then you'll get more
numbers on each line and the lines will have these fields: