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



        </figure></para>
 
      <section>
        <title>Implementation</title>
 
        <para>The buddy allocator is, in fact, an abstract framework which 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 with an
        implementation of this interface, the buddy allocator can use

    multiple copies of the same program, linked to the same addresses, running
    in the system. There are at least two known mechanisms for implementing
    virtual memory: segmentation and paging. Even though some processor
    architectures supported by HelenOS<footnote>
        <para>ia32 has full-fledged segmentation.</para>
      </footnote> provide both mechanisms, the kernel makes use solely of
    paging.</para>
 
    <section id="paging">
      <title>VAT subsystem</title>
 
      <para>In a paged virtual memory, the entire virtual address space is
      divided into small power-of-two sized naturally aligned blocks called
      pages. The processor implements a translation mechanism, that allows the
      operating system to manage mappings between set of pages and set of
      identically sized and identically aligned pieces of physical memory
      called frames. In a result, references to continuous virtual memory
      areas don't necessarily need to reference continuos area of physical
      memory. Supported page sizes usually range from several kilobytes to
      several megabytes. Each page that takes part in the mapping is
      associated with certain attributes that further desribe the mapping

        each address space has its own page tables. To avoid confusion in
        terminology used by hardware vendors, in HelenOS, the root level page
        table is called PTL0, the two middle levels are called PTL1 and PTL2,
        and, finally, the leaf level is called PTL3. All architectures using
        this mechanism are required to use PTL0 and PTL3. However, the middle
        levels can be left out, depending on the hardware hierarchy or
        structure of software-only page tables. The genericity is achieved
        through a set of macros that define transitions from one level to
        another. Unused levels are optimised out by the compiler.
    <figure float="1">
          <mediaobject id="mm_pt">

      associating TLB entries with address spaces through assigning
      identification numbers to them. In HelenOS, the term ASID, originally
      taken from the mips32 terminology, is used to refer to the address space
      identification number. The advantage of having ASIDs is that TLB does
      not have to be invalidated on thread context switch as long as ASIDs are
      unique. Unfortunately, architectures supported by HelenOS use all
      different widths of ASID numbers<footnote>
          <para>amd64 and ia32 don't use similar abstraction at all, mips32
          has 8-bit ASIDs and ia64 can have ASIDs between 18 to 24 bits
          wide.</para>
        </footnote> out of which none is sufficient. The amd64 and ia32

Subversion Repositories HelenOS-doc

(root)/design/trunk/src/ch_memory_management.xml – Rev 168 → 169

Rev 168		Rev 169
Line 141...		Line 141...
141	</figure></para>	141	</figure></para>
142		142
143	<section>	143	<section>
144	<title>Implementation</title>	144	<title>Implementation</title>
145		145
146	<para>The buddy allocator is, in fact, an abstract framework wich can	146	<para>The buddy allocator is, in fact, an abstract framework which can
147	be easily specialized to serve one particular task. It knows nothing	147	be easily specialized to serve one particular task. It knows nothing
148	about the nature of memory it helps to allocate. In order to beat the	148	about the nature of memory it helps to allocate. In order to beat the
149	lack of this knowledge, the buddy allocator exports an interface that	149	lack of this knowledge, the buddy allocator exports an interface that
150	each of its clients is required to implement. When supplied with an	150	each of its clients is required to implement. When supplied with an
151	implementation of this interface, the buddy allocator can use	151	implementation of this interface, the buddy allocator can use
Line 363...		Line 363...
363	multiple copies of the same program, linked to the same addresses, running	363	multiple copies of the same program, linked to the same addresses, running
364	in the system. There are at least two known mechanisms for implementing	364	in the system. There are at least two known mechanisms for implementing
365	virtual memory: segmentation and paging. Even though some processor	365	virtual memory: segmentation and paging. Even though some processor
366	architectures supported by HelenOS<footnote>	366	architectures supported by HelenOS<footnote>
367	<para>ia32 has full-fledged segmentation.</para>	367	<para>ia32 has full-fledged segmentation.</para>
368	</footnote> provide both mechanism, the kernel makes use solely of	368	</footnote> provide both mechanisms, the kernel makes use solely of
369	paging.</para>	369	paging.</para>
370		370
371	<section id="paging">	371	<section id="paging">
372	<title>VAT subsystem</title>	372	<title>VAT subsystem</title>
373		373
374	<para>In a paged virtual memory, the entire virtual address space is	374	<para>In a paged virtual memory, the entire virtual address space is
375	divided into small power-of-two sized naturally aligned blocks called	375	divided into small power-of-two sized naturally aligned blocks called
376	pages. The processor implements a translation mechanism, that allows the	376	pages. The processor implements a translation mechanism, that allows the
377	operating system to manage mappings between set of pages and set of	377	operating system to manage mappings between set of pages and set of
378	indentically sized and identically aligned pieces of physical memory	378	identically sized and identically aligned pieces of physical memory
379	called frames. In a result, references to continuous virtual memory	379	called frames. In a result, references to continuous virtual memory
380	areas don't necessarily need to reference continuos area of physical	380	areas don't necessarily need to reference continuos area of physical
381	memory. Supported page sizes usually range from several kilobytes to	381	memory. Supported page sizes usually range from several kilobytes to
382	several megabytes. Each page that takes part in the mapping is	382	several megabytes. Each page that takes part in the mapping is
383	associated with certain attributes that further desribe the mapping	383	associated with certain attributes that further desribe the mapping
Line 460...		Line 460...
460	each address space has its own page tables. To avoid confusion in	460	each address space has its own page tables. To avoid confusion in
461	terminology used by hardware vendors, in HelenOS, the root level page	461	terminology used by hardware vendors, in HelenOS, the root level page
462	table is called PTL0, the two middle levels are called PTL1 and PTL2,	462	table is called PTL0, the two middle levels are called PTL1 and PTL2,
463	and, finally, the leaf level is called PTL3. All architectures using	463	and, finally, the leaf level is called PTL3. All architectures using
464	this mechanism are required to use PTL0 and PTL3. However, the middle	464	this mechanism are required to use PTL0 and PTL3. However, the middle
465	levels can be left out, depending on the hardware hierachy or	465	levels can be left out, depending on the hardware hierarchy or
466	structure of software-only page tables. The genericity is achieved	466	structure of software-only page tables. The genericity is achieved
467	through a set of macros that define transitions from one level to	467	through a set of macros that define transitions from one level to
468	another. Unused levels are optimised out by the compiler.	468	another. Unused levels are optimised out by the compiler.
469	<figure float="1">	469	<figure float="1">
470	<mediaobject id="mm_pt">	470	<mediaobject id="mm_pt">
Line 784...		Line 784...
784	associating TLB entries with address spaces through assigning	784	associating TLB entries with address spaces through assigning
785	identification numbers to them. In HelenOS, the term ASID, originally	785	identification numbers to them. In HelenOS, the term ASID, originally
786	taken from the mips32 terminology, is used to refer to the address space	786	taken from the mips32 terminology, is used to refer to the address space
787	identification number. The advantage of having ASIDs is that TLB does	787	identification number. The advantage of having ASIDs is that TLB does
788	not have to be invalidated on thread context switch as long as ASIDs are	788	not have to be invalidated on thread context switch as long as ASIDs are
789	unique. Unfortunatelly, architectures supported by HelenOS use all	789	unique. Unfortunately, architectures supported by HelenOS use all
790	different widths of ASID numbers<footnote>	790	different widths of ASID numbers<footnote>
791	<para>amd64 and ia32 don't use similar abstraction at all, mips32	791	<para>amd64 and ia32 don't use similar abstraction at all, mips32
792	has 8-bit ASIDs and ia64 can have ASIDs between 18 to 24 bits	792	has 8-bit ASIDs and ia64 can have ASIDs between 18 to 24 bits
793	wide.</para>	793	wide.</para>
794	</footnote> out of which none is sufficient. The amd64 and ia32	794	</footnote> out of which none is sufficient. The amd64 and ia32