This variable applies for the whole cache unlike the perCPU touched element
next_reap defines a time interval that the kernel must allow to elapse between two attempts to shrink the cache. The idea is to prevent degradation of system performance due to frequent cache shrinking and growing operations as can happen in certain load situations. This technique is only used on NUMA systems and will thus not concern us any further.
free_limit specifies the maximum number of unused objects permitted on all slabs.
The structure is concluded by pointers to array_cache instances that are either shared per node or originate from other nodes. This is of relevance on NUMA machines but, for the sake of simplicity, this won't be discussed in detail.
The third part of kmem_cache contains all variables needed to grow (and shrink) the cache.
□ gfporder specifies the slab size as a binary logarithm of the number of pages, or, expressed differently, the slab comprises 2gfporder pages.
□ The three colour elements hold all relevant data for slab coloring.
colour specifies the maximum number of colors and colour_next the color to use for the next slab created by the kernel. Note, however, that this value is specified as an element of kmem_list3. colour_off is the basic offset multiplied by a color value to obtain the absolute offset. This is again required for NUMA machines — UMA systems could keep colour_next in struct kmem_cache. Placing the next color in a node-specific structure, however, allows coloring slabs added on the same node sequentially, which is beneficial for the local caches.
Example: If there are five possible colors (0,1,2,3,4) and the offset unit is 8 bytes, the kernel can use the following offset values: 0 x 8 = 0,1 x 8 = 8,2 x 8 = 16,3 x 8 = 24 and 4 x 8 = 32 bytes.
Section 3.6.4 examines how the kernel determines the possible settings for slab colors. Besides, note that the kernel sources, in contrast to this book, spell colour properly, at least from the British point of view.
□ If the slab head is stored outside the slab, slabp_cache points to the general cache from which the required memory is taken. If the slab head is on-slab, slabp_cache contains a null pointer.
□ dflags is a further set of flags that describe the ''dynamic properties'' of the slab, but currently no flags are defined.
□ ctor is a pointer to a constructor function that is invoked when objects are created. This method is well known in object-oriented languages such as C++ and Java. Former kernel versions did offer the ability to specify an additional destructor function, but since this opportunity was not used, it has been dropped during the development of kernel 2.6.22.
The fifth and last part (statistics fields that are of no further interest for our purposes) of struct kmem_cache consists of two further elements:
□ name is a string containing a human-readable name for the cache. It is used, for example, to list the available caches in /proc/slabinfo.
□ next is a standard list element to keep all instances of kmem_cache on the global list cache_chain.
Continue reading here: Initialization
Was this article helpful?