Chapter3:MemoryManagement
Recall from Figure 3-47 that the kernel uses an interesting system to keep track of free entries: The index
of the free object that is currently under consideration is stored inslabp->free, and the index of the next
free object, is kept in the management array.
Obtaining the object that belongs to a given index is a matter of some simple pointer manipulation per-
formed inindex_to_obj.slab_bufctlis a macro that yields a pointer to thekmem_bufctlarray after
slabp.
Let us return tocache_alloc_grow. If no free object is found although all slabs have been scanned, the
cache must be enlarged usingcache_grow. This is a costly operation examined in the next section.
Growing the Cache
Figure 3-51 shows the code flow diagram forcache_grow.
Compute offset and next color
Set page pointer
Add slab to cache
cache_grow
kmem_getpages
alloc_slabmgt
alloc_pages_node
cache_init_objs
Figure 3-51: Code flow diagram forcache_grow.
The arguments ofkmem_cache_allocare passed tocache_grow. It is also possible to specify an explicit
node from which the fresh memory pages are to be supplied.
The color and offset are first calculated:
mm/slab.c
static int cache_grow(struct kmem_cache *cachep,
gfp_t flags, int nodeid, void *objp)
{
...
l3 = cachep->nodelists[nodeid];
...
offset = l3->colour_next;
l3->colour_next++;
if (l3->colour_next >= cachep->colour)
l3->colour_next = 0;
offset *= cachep->colour_off;
...
}