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



 
  <section>
    <title>Physical memory management</title>
 
    <section id="zones_and_frames">
      <indexterm><primary>memory management</primary><secondary>memory zone</secondary></indexterm>
      <title>Zones and frames</title>
 
      <para>HelenOS represents continuous areas of physical memory in
      structures called frame zones (abbreviated as zones). Each zone contains
      information about the number of allocated and unallocated physical

      structure that contains number of references and data used by buddy
      system.</para>
    </section>
 
    <section id="frame_allocator">
      <indexterm><primary>memory management</primary><secondary>frame allocator</secondary></indexterm>
      <title>Frame allocator</title>
 
      <para>The frame allocator satisfies kernel requests to allocate
      power-of-two sized blocks of physical memory. Because of zonal
      organization of physical memory, the frame allocator is always working

        to take care of deallocation within the zone's buddy system.</para>
      </formalpara>
    </section>
 
    <section id="buddy_allocator">
      <indexterm><primary>memory management</primary><secondary>buddy system</secondary></indexterm>
      <title>Buddy allocator</title>
 
      <para>In the buddy system, the memory is broken down into power-of-two
      sized naturally aligned blocks. These blocks are organized in an array
      of lists, in which the list with index i contains all unallocated blocks

        </formalpara>
      </section>
    </section>
 
    <section id="slab">
    <indexterm><primary>memory management</primary><secondary>slab</secondary></indexterm>      
    <title>Slab allocator</title>
 
      <para>The majority of memory allocation requests in the kernel is for
      small, frequently used data structures. The basic idea behind the slab
      allocator is that commonly used objects are preallocated in continuous
      areas of physical memory called slabs<footnote>

               dynamic magazine grow (different magazine sizes are already supported, but the allocation strategy would need to be adjusted)
            </listitem>
          </itemizedlist></para>
 
        <section>
        <indexterm><primary>memory management</primary><secondary>slab magazine</secondary></indexterm>
        <title>Magazine layer</title>
 
          <para>Due to the extensive bottleneck on SMP architures, caused by
          global slab locking mechanism, making processing of all slab
          allocation requests serialized, a new layer was introduced to the
          classic slab allocator design. Slab allocator was extended to

 
    <section>
      <title>Address spaces</title>
 
      <section>
    <indexterm><primary>memory management</primary><secondary>address space area</secondary></indexterm>
    <title>Address space areas</title>
 
        <para>Each address space consists of mutually disjunctive continuous
        address space areas. Address space area is precisely defined by its
        base address and the number of frames/pages is contains.</para>
 

        <para>Kernel provides possibility tasks create/expand/shrink/share its
        address space via the set of syscalls.</para>
      </section>
 
      <section>
    <indexterm><primary>memory management</primary><secondary>asid</secondary></indexterm>
        <title>Address Space ID (ASID)</title>
 
        <para>When switching to the different task, kernel also require to
        switch mappings to the different address space. In case TLB cannot
        distinguish address space mappings, all mapping information in TLB

          access to the virtual address, CPU performs <emphasis>address
          translation</emphasis> during the instruction execution.
          Non-existing mapping generates page fault exception, calling kernel
          exception handler, thus allowing kernel to manipulate rules of
          memory access. Information for pages mapping is stored by kernel in
          the page tables</para>
 
          <para>The majority of the architectures use multi-level page tables,
          which means need to access physical memory several times before
          getting physical address. This fact would make serios performance
          overhead in virtual memory management. To avoid this <link

              </listitem>
            </itemizedlist></para>
        </section>
 
        <section>
      <indexterm><primary>memory management</primary><secondary>hash table</secondary></indexterm>          
      <title>Global hash table</title>
 
          <para>Implementation of the global hash table was encouraged by the
          ia64 architecture support. One of the major differences between
          global hash table and hierarchical tables is that global hash table
          exists only once in the system and the hierarchical tables are

          <para>Collision chains ...</para>
        </section>
      </section>
 
      <section id="tlb">
        <indexterm><primary>memory management</primary><secondary>tlb</secondary></indexterm>
        <title>Translation Lookaside buffer</title>
 
        <para>Due to the extensive overhead during the page mapping lookup in
        the page tables, all architectures has fast assotiative cache memory
        built-in CPU. This memory called TLB stores recently used page table

Rev 68	Rev 69
Line 12...	Line 12...
12		12
13	<section>	13	<section>
14	<title>Physical memory management</title>	14	<title>Physical memory management</title>
15		15
16	<section id="zones_and_frames">	16	<section id="zones_and_frames">
-		17	<indexterm><primary>memory management</primary><secondary>memory zone</secondary></indexterm>
17	<title>Zones and frames</title>	18	<title>Zones and frames</title>
18		19
19	<para>HelenOS represents continuous areas of physical memory in	20	<para>HelenOS represents continuous areas of physical memory in
20	structures called frame zones (abbreviated as zones). Each zone contains	21	structures called frame zones (abbreviated as zones). Each zone contains
21	information about the number of allocated and unallocated physical	22	information about the number of allocated and unallocated physical
Line 42...	Line 43...
42	structure that contains number of references and data used by buddy	43	structure that contains number of references and data used by buddy
43	system.</para>	44	system.</para>
44	</section>	45	</section>
45		46
46	<section id="frame_allocator">	47	<section id="frame_allocator">
-		48	<indexterm><primary>memory management</primary><secondary>frame allocator</secondary></indexterm>
47	<title>Frame allocator</title>	49	<title>Frame allocator</title>
48		50
49	<para>The frame allocator satisfies kernel requests to allocate	51	<para>The frame allocator satisfies kernel requests to allocate
50	power-of-two sized blocks of physical memory. Because of zonal	52	power-of-two sized blocks of physical memory. Because of zonal
51	organization of physical memory, the frame allocator is always working	53	organization of physical memory, the frame allocator is always working
Line 81...	Line 83...
81	to take care of deallocation within the zone's buddy system.</para>	83	to take care of deallocation within the zone's buddy system.</para>
82	</formalpara>	84	</formalpara>
83	</section>	85	</section>
84		86
85	<section id="buddy_allocator">	87	<section id="buddy_allocator">
-		88	<indexterm><primary>memory management</primary><secondary>buddy system</secondary></indexterm>
86	<title>Buddy allocator</title>	89	<title>Buddy allocator</title>
87		90
88	<para>In the buddy system, the memory is broken down into power-of-two	91	<para>In the buddy system, the memory is broken down into power-of-two
89	sized naturally aligned blocks. These blocks are organized in an array	92	sized naturally aligned blocks. These blocks are organized in an array
90	of lists, in which the list with index i contains all unallocated blocks	93	of lists, in which the list with index i contains all unallocated blocks
Line 155...	Line 158...
155	</formalpara>	158	</formalpara>
156	</section>	159	</section>
157	</section>	160	</section>
158		161
159	<section id="slab">	162	<section id="slab">
-		163	<indexterm><primary>memory management</primary><secondary>slab</secondary></indexterm>
160	<title>Slab allocator</title>	164	<title>Slab allocator</title>
161		165
162	<para>The majority of memory allocation requests in the kernel is for	166	<para>The majority of memory allocation requests in the kernel is for
163	small, frequently used data structures. The basic idea behind the slab	167	small, frequently used data structures. The basic idea behind the slab
164	allocator is that commonly used objects are preallocated in continuous	168	allocator is that commonly used objects are preallocated in continuous
165	areas of physical memory called slabs<footnote>	169	areas of physical memory called slabs<footnote>
Line 238...	Line 242...
238	dynamic magazine grow (different magazine sizes are already supported, but the allocation strategy would need to be adjusted)	242	dynamic magazine grow (different magazine sizes are already supported, but the allocation strategy would need to be adjusted)
239	</listitem>	243	</listitem>
240	</itemizedlist></para>	244	</itemizedlist></para>
241		245
242	<section>	246	<section>
-		247	<indexterm><primary>memory management</primary><secondary>slab magazine</secondary></indexterm>
243	<title>Magazine layer</title>	248	<title>Magazine layer</title>
244		249
245	<para>Due to the extensive bottleneck on SMP architures, caused by	250	<para>Due to the extensive bottleneck on SMP architures, caused by
246	global slab locking mechanism, making processing of all slab	251	global slab locking mechanism, making processing of all slab
247	allocation requests serialized, a new layer was introduced to the	252	allocation requests serialized, a new layer was introduced to the
248	classic slab allocator design. Slab allocator was extended to	253	classic slab allocator design. Slab allocator was extended to
Line 376...	Line 381...
376		381
377	<section>	382	<section>
378	<title>Address spaces</title>	383	<title>Address spaces</title>
379		384
380	<section>	385	<section>
-		386	<indexterm><primary>memory management</primary><secondary>address space area</secondary></indexterm>
381	<title>Address space areas</title>	387	<title>Address space areas</title>
382		388
383	<para>Each address space consists of mutually disjunctive continuous	389	<para>Each address space consists of mutually disjunctive continuous
384	address space areas. Address space area is precisely defined by its	390	address space areas. Address space area is precisely defined by its
385	base address and the number of frames/pages is contains.</para>	391	base address and the number of frames/pages is contains.</para>
386		392
Line 422...	Line 428...
422	<para>Kernel provides possibility tasks create/expand/shrink/share its	428	<para>Kernel provides possibility tasks create/expand/shrink/share its
423	address space via the set of syscalls.</para>	429	address space via the set of syscalls.</para>
424	</section>	430	</section>
425		431
426	<section>	432	<section>
-		433	<indexterm><primary>memory management</primary><secondary>asid</secondary></indexterm>
427	<title>Address Space ID (ASID)</title>	434	<title>Address Space ID (ASID)</title>
428		435
429	<para>When switching to the different task, kernel also require to	436	<para>When switching to the different task, kernel also require to
430	switch mappings to the different address space. In case TLB cannot	437	switch mappings to the different address space. In case TLB cannot
431	distinguish address space mappings, all mapping information in TLB	438	distinguish address space mappings, all mapping information in TLB
Line 471...	Line 478...
471	access to the virtual address, CPU performs <emphasis>address	478	access to the virtual address, CPU performs <emphasis>address
472	translation</emphasis> during the instruction execution.	479	translation</emphasis> during the instruction execution.
473	Non-existing mapping generates page fault exception, calling kernel	480	Non-existing mapping generates page fault exception, calling kernel
474	exception handler, thus allowing kernel to manipulate rules of	481	exception handler, thus allowing kernel to manipulate rules of
475	memory access. Information for pages mapping is stored by kernel in	482	memory access. Information for pages mapping is stored by kernel in
476	the <link linkend="page_tables">page tables</link></para>	483	the page tables</para>
477		484
478	<para>The majority of the architectures use multi-level page tables,	485	<para>The majority of the architectures use multi-level page tables,
479	which means need to access physical memory several times before	486	which means need to access physical memory several times before
480	getting physical address. This fact would make serios performance	487	getting physical address. This fact would make serios performance
481	overhead in virtual memory management. To avoid this <link	488	overhead in virtual memory management. To avoid this <link
Line 519...	Line 526...
519	</listitem>	526	</listitem>
520	</itemizedlist></para>	527	</itemizedlist></para>
521	</section>	528	</section>
522		529
523	<section>	530	<section>
-		531	<indexterm><primary>memory management</primary><secondary>hash table</secondary></indexterm>
524	<title>Global hash table</title>	532	<title>Global hash table</title>
525		533
526	<para>Implementation of the global hash table was encouraged by the	534	<para>Implementation of the global hash table was encouraged by the
527	ia64 architecture support. One of the major differences between	535	ia64 architecture support. One of the major differences between
528	global hash table and hierarchical tables is that global hash table	536	global hash table and hierarchical tables is that global hash table
529	exists only once in the system and the hierarchical tables are	537	exists only once in the system and the hierarchical tables are
Line 542...	Line 550...
542	<para>Collision chains ...</para>	550	<para>Collision chains ...</para>
543	</section>	551	</section>
544	</section>	552	</section>
545		553
546	<section id="tlb">	554	<section id="tlb">
-		555	<indexterm><primary>memory management</primary><secondary>tlb</secondary></indexterm>
547	<title>Translation Lookaside buffer</title>	556	<title>Translation Lookaside buffer</title>
548		557
549	<para>Due to the extensive overhead during the page mapping lookup in	558	<para>Due to the extensive overhead during the page mapping lookup in
550	the page tables, all architectures has fast assotiative cache memory	559	the page tables, all architectures has fast assotiative cache memory
551	built-in CPU. This memory called TLB stores recently used page table	560	built-in CPU. This memory called TLB stores recently used page table

Subversion Repositories HelenOS-doc

(root)/design/trunk/src/ch_memory_management.xml @ 129 – Rev 68 → 69