Rev 185 | Show entire file | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed
Rev 185 | Rev 186 | ||
---|---|---|---|
Line 80... | Line 80... | ||
80 | 80 | ||
81 | <para>Upon allocation request via function <code>frame_alloc()</code>, |
81 | <para>Upon allocation request via function <code>frame_alloc()</code>, |
82 | the frame allocator first tries to find a zone that can satisfy the |
82 | the frame allocator first tries to find a zone that can satisfy the |
83 | request (i.e. has the required amount of free frames). Once a suitable |
83 | request (i.e. has the required amount of free frames). Once a suitable |
84 | zone is found, the frame allocator uses the buddy allocator on the |
84 | zone is found, the frame allocator uses the buddy allocator on the |
85 | zone's buddy system to perform the allocation. During deallocation, |
85 | zone's buddy system to perform the allocation. If no free zone is |
86 | which is triggered by a call to <code>frame_free()</code>, the frame |
86 | found, the frame allocator tries to reclaim slab memory.</para> |
- | 87 | ||
87 | allocator looks up the respective zone that contains the frame being |
88 | <para>During deallocation, which is triggered by a call to |
88 | deallocated. Afterwards, it calls the buddy allocator again, this time |
89 | <code>frame_free()</code>, the frame allocator looks up the respective |
- | 90 | zone that contains the frame being deallocated. Afterwards, it calls |
|
- | 91 | the buddy allocator again, this time to take care of deallocation |
|
89 | to take care of deallocation within the zone's buddy system.</para> |
92 | within the zone's buddy system.</para> |
90 | </formalpara> |
93 | </formalpara> |
91 | </section> |
94 | </section> |
92 | 95 | ||
93 | <section id="buddy_allocator"> |
96 | <section id="buddy_allocator"> |
94 | <indexterm> |
97 | <indexterm> |
Line 162... | Line 165... | ||
162 | 165 | ||
163 | <para>Whatever entities are allocated by the buddy allocator, the |
166 | <para>Whatever entities are allocated by the buddy allocator, the |
164 | first entity within a block is used to represent the entire block. |
167 | first entity within a block is used to represent the entire block. |
165 | The first entity keeps the order of the whole block. Other entities |
168 | The first entity keeps the order of the whole block. Other entities |
166 | within the block are assigned the magic value |
169 | within the block are assigned the magic value |
167 | <constant>BUDDY_INNER_BLOCK</constant>. This is especially important |
170 | <constant>BUDDY_SYSTEM_INNER_BLOCK</constant>. This is especially important |
168 | for effective identification of buddies in a one-dimensional array |
171 | for effective identification of buddies in a one-dimensional array |
169 | because the entity that represents a potential buddy cannot be |
172 | because the entity that represents a potential buddy cannot be |
170 | associated with <constant>BUDDY_INNER_BLOCK</constant> (i.e. if it |
173 | associated with <constant>BUDDY_SYSTEM_INNER_BLOCK</constant> (i.e. if it |
171 | is associated with <constant>BUDDY_INNER_BLOCK</constant> then it is |
174 | is associated with <constant>BUDDY_SYSTEM_INNER_BLOCK</constant> then it is |
172 | not a buddy).</para> |
175 | not a buddy).</para> |
173 | </formalpara> |
176 | </formalpara> |
174 | </section> |
177 | </section> |
175 | </section> |
178 | </section> |
176 | 179 | ||
Line 201... | Line 204... | ||
201 | 204 | ||
202 | <secondary>- slab cache</secondary> |
205 | <secondary>- slab cache</secondary> |
203 | </indexterm> |
206 | </indexterm> |
204 | 207 | ||
205 | <para>Slabs of one object type are organized in a structure called slab |
208 | <para>Slabs of one object type are organized in a structure called slab |
206 | cache. There are ususally more slabs in the slab cache, depending on |
209 | cache. There are usually more slabs in the slab cache, depending on |
207 | previous allocations. If the the slab cache runs out of available slabs, |
210 | previous allocations. If the the slab cache runs out of available slabs, |
208 | new slabs are allocated. In order to exploit parallelism and to avoid |
211 | new slabs are allocated. In order to exploit parallelism and to avoid |
209 | locking of shared spinlocks, slab caches can have variants of |
212 | locking of shared spinlocks, slab caches can have variants of |
210 | processor-private slabs called magazines. On each processor, there is a |
213 | processor-private slabs called magazines. On each processor, there is a |
211 | two-magazine cache. Full magazines that are not part of any |
214 | two-magazine cache. Full magazines that are not part of any |