Библиотека сайта rus-linux.net
The book is available and called simply "Understanding The Linux Virtual Memory Manager". There is a lot of additional material in the book that is not available here, including details on later 2.4 kernels, introductions to 2.6, a whole new chapter on the shared memory filesystem, coverage of TLB management, a lot more code commentary, countless other additions and clarifications and a CD with lots of cool stuff on it. This material (although now dated and lacking in comparison to the book) will remain available although I obviously encourge you to buy the book from your favourite book store :-) . As the book is under the Bruce Perens Open Book Series, it will be available 90 days after appearing on the book shelves which means it is not available right now. When it is available, it will be downloadable from http://www.phptr.com/perens so check there for more information.
To be fully clear, this webpage is not the actual book.
Next: 9.4 Sizes Cache Up: 9. Slab Allocator Previous: 9.2 Slabs Contents Index
Subsections
9.3 Objects
This section will cover how objects are managed. At this point, most of the really hard work has been completed by either the cache or slab managers.
9.3.1 Initialising Objects in a Slab
When a slab is created, all the objects in it are put in an initialised
state. If a constructor is available, it is called for each object and it is
expected that objects are left in an initialised state upon free. Conceptually
the initialisation is very simple, cycle through all objects and call the
constructor and initialise the kmem_bufctl for it. The function
kmem_cache_init_objs() is responsible for initialising the objects.
9.3.2 Object Allocation
The function kmem_cache_alloc() is responsible for allocating
one object to the caller which behaves slightly different in the UP and SMP
cases. Figure 9.13 shows the basic call graph that
is used to allocate an object in the SMP case.
![\includegraphics[width=17cm]{graphs/kmem_cache_alloc-UP.ps}](/MyLDP/BOOKS/VirtMem/img94.png)
There are four basic steps. The first step
(kmem_cache_alloc_head()) covers basic checking to make sure
the allocation is allowable. The second step is to select which slabs
list to allocate from. This will be one of slabs_partial or
slabs_free. If there are no slabs in slabs_free,
the cache is grown (see Section 9.2.2) to create a new
slab in slabs_free. The final step is to allocate the object
from the selected slab.
The SMP case takes one further step. Before allocating one object, it will
check to see if there is one available from the per-CPU cache and will use
it if there is. If there is not, it will allocate batchcount number
of objects in bulk and place them in its per-cpu cache. See Section 9.5 for more information on the per-cpu caches.
9.3.3 Object Freeing
kmem_cache_free() is used to free objects and it has a relatively
simple task. Just like kmem_cache_alloc(), it behaves differently
in the UP and SMP cases. The principal difference between the two cases is
that in the UP case, the object is returned directly to the slab but with the
SMP case, the object is returned to the per-cpu cache. In both cases, the
destructor for the object will be called if one is available. The destructor
is responsible for returning the object to the initialised state.
Next: 9.4 Sizes Cache Up: 9. Slab Allocator Previous: 9.2 Slabs Contents Index Mel 2004-02-15