WebSVN – HelenOS-doc – Diff – /design/trunk/src/ch_memory_management.xml

             <imageobject role="fop">
               <imagedata fileref="images.vector/buddy_alloc.svg" format="SVG" />
             </imageobject>
           </mediaobject></para>
-        <para>In buddy allocator, memory is broken down into power-of-two
+        <para>In the buddy allocator, the memory is broken down into
-        sized naturally aligned blocks. These blocks are organized in an array
+        power-of-two sized naturally aligned blocks. These blocks are
+        organized in an array of lists, in which the list with index i
-        of lists in which list with index i contains all unallocated blocks of
+        contains all unallocated blocks of size
-        the size <mathphrase>2<superscript>i</superscript></mathphrase>. The
+        <mathphrase>2<superscript>i</superscript></mathphrase>. The index i is
-        index i is called the order of block. Should there be two adjacent
+        called the order of block. Should there be two adjacent equally sized
-        equally sized blocks in list <mathphrase>i</mathphrase> (i.e.
+        blocks in the list i<mathphrase> </mathphrase>(i.e. buddies), the
-        buddies), the buddy allocator would coalesce them and put the
+        buddy allocator would coalesce them and put the resulting block in
-        resulting block in list <mathphrase>i + 1</mathphrase>, provided that
+        list <mathphrase>i + 1</mathphrase>, provided that the resulting block
-        the resulting block would be naturally aligned. Similarily, when the
+        would be naturally aligned. Similarily, when the allocator is asked to
-        allocator is asked to allocate a block of size
+        allocate a block of size
         <mathphrase>2<superscript>i</superscript></mathphrase>, it first tries
-        to satisfy the request from list with index i. If the request cannot
+        to satisfy the request from the list with index i. If the request
-        be satisfied (i.e. the list i is empty), the buddy allocator will try
+        cannot be satisfied (i.e. the list i is empty), the buddy allocator
-        to allocate and split larger block from list with index i + 1. Both of
+        will try to allocate and split a larger block from the list with index
-        these algorithms are recursive. The recursion ends either when there
+        i + 1. Both of these algorithms are recursive. The recursion ends
-        are no blocks to coalesce in the former case or when there are no
+        either when there are no blocks to coalesce in the former case or when
-        blocks that can be split in the latter case.</para>
+        there are no blocks that can be split in the latter case.</para>
         <!--graphic fileref="images/mm1.png" format="EPS" /-->
         <para>This approach greatly reduces external fragmentation of memory
         and helps in allocating bigger continuous blocks of memory aligned to
         <para>The buddy allocator is, in fact, an abstract framework wich can
         be easily specialized to serve one particular task. It knows nothing
         about the nature of memory it helps to allocate. In order to beat the
         lack of this knowledge, the buddy allocator exports an interface that
-        each of its clients is required to implement. When supplied an
+        each of its clients is required to implement. When supplied with an
         implementation of this interface, the buddy allocator can use
-        specialized external functions to find buddy for a block, split and
+        specialized external functions to find a buddy for a block, split and
         coalesce blocks, manipulate block order and mark blocks busy or
-        available. For precize documentation of this interface, refer to
+        available. For precise documentation of this interface, refer to
         <emphasis>"HelenOS Generic Kernel Reference Manual"</emphasis>.</para>
         <formalpara>
           <title>Data organization</title>
           <para>Whatever entities are allocated by the buddy allocator, the
           first entity within a block is used to represent the entire block.
           The first entity keeps the order of the whole block. Other entities
           within the block are assigned the magic value
           <constant>BUDDY_INNER_BLOCK</constant>. This is especially important
-          for effective identification of buddies in one-dimensional array
+          for effective identification of buddies in a one-dimensional array
           because the entity that represents a potential buddy cannot be
           associated with <constant>BUDDY_INNER_BLOCK</constant> (i.e. if it
           is associated with <constant>BUDDY_INNER_BLOCK</constant> then it is
           not a buddy).</para>
-          <para>Buddy allocator always uses first frame to represent frame
+          <para>The buddy allocator always uses the first frame to represent
-          block. This frame contains <varname>buddy_order</varname> variable
+          the frame block. This frame contains <varname>buddy_order</varname>
-          to provide information about the block size it actually represents (
+          variable to provide information about the block size it actually
+          represents (
           <mathphrase>2<superscript>buddy_order</superscript></mathphrase>
           frames block). Other frames in block have this value set to magic
           <constant>BUDDY_INNER_BLOCK</constant> that is much greater than
           buddy <varname>max_order</varname> value.</para>

Subversion Repositories HelenOS-doc

(root)/design/trunk/src/ch_memory_management.xml – Rev 39 → 45