Subversion Repositories HelenOS-doc

      <para>Virtual memory is a special memory management technique, used by

      kernel to achieve a bunch of mission critical goals. <itemizedlist>

             Isolate each task from other tasks that are running on the system at the same time.

          </listitem>

          <listitem>

             Allow to allocate more memory, than is actual physical memory size of the machine.

          </listitem>

          <listitem>

             Allowing, in general, to load and execute two programs that are linked on the same address without complicated relocations.

          </listitem>

        </itemizedlist></para>

      <para>Virtual memory is usually using paged memory model, where virtual

      memory address space is divided into the <emphasis>pages</emphasis>

      (usually having size 4096 bytes) and physical memory is divided into the

      frames (same sized as a page, of cause). Each page may be mapped to some

      frame and then, upon memory 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

      <link linkend="page_tables">page tables</link></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 linkend="tlb">Traslation

      Lookaside Buffer (TLB)</link> is used.</para>

      <para>At the moment HelenOS does not support swapping.</para>

       - pouzivame vypadky stranky k alokaci ramcu on-demand v ramci as_area - na architekturach, ktere to podporuji, podporujeme non-exec stranky

      <section>

        usporadanych v B+stromu; tyto areas popisuji vyuzivane casti

        svoji bazovou adresou, velikosti a flagy (rwx/dd).</para>

        <para>- uzivatelske thready maji moznost manipulovat se svym adresovym

        prostorem (vytvaret/resizovat/sdilet) as_areas pomoci syscallu</para>

      </section>

      <section>

        <title>Address Space ID (ASID)</title>

        <para>- nektery hardware umoznuje rozlisit ruzne adresove prostory od

        sebe (cilem je maximalizovat vyuziti TLB); dela to tak, ze s kazdou

        polozkou TLB/strankovacich tabulek sdruzi identifikator adresoveho

        prostoru (ASID, RID, ppc32 ???). Tyto id mivaji ruznou sirku: 8-bitu

        az 24-bitu (kolik ma ppc32?)</para>

        <para>- kernel tomu rozumi a sam pouziva abstrakci ASIDu (na ia64 to

        je napr. cislo odvozene od RIDu, na mips32 to je ASID samotny);

        existence ASIDu je nutnou podminkou pouziti _global_ page hash table

        mechanismu.</para>

        <para>- na vsech arch. plati, ze asidu je mnohem mene, nez teoreticky

        implementovan mechanismus, ktery umoznuje jednomu adresovemu prostoru

        je adresovy prostor sdilen vice tasky, avsak tuto moznost nepouzivame

        a neni ani nijak osetrena. Tim padem plati, ze kazdy task ma vlastni

        adresovy prostor</para>

      </section>

    </section>

    <section>

      <title>Virtual address translation</title>

      <section id="page_tables">

        <title>Page tables</title>

        <para>HelenOS kernel has two different approaches to the paging

        implementation: <emphasis>4 level page tables</emphasis> and

        generic paging abstraction layer. This division was caused by the

        major architectural differences between different platforms.</para>

        <formalpara>

          <title>4-level page tables</title>

          <para>4-level page tables are the generalization of the hardware

          capabilities of the certain platforms. <itemizedlist>

              <listitem>

              </listitem>

              <listitem>

                 amd64 uses 4-level page tables, also coming with full hardware support.

              </listitem>

              <listitem>

                 mips and ppc32 have 2-level tables, software simulated support.

              </listitem>

            </itemizedlist></para>

        </formalpara>

        <formalpara>

          <title>Global hash tables</title>

          <para>- global page hash table: existuje jen jedna v celem systemu

          (vyuziva ji ia64), pozn. ia64 ma zatim vypnuty VHPT. Pouziva se

          genericke hash table s oddelenymi collision chains</para>

        </formalpara>

        left have more paging implementations, for example B-Tree page

      </section>

      <section id="tlb">

        <title>Translation Lookaside buffer</title>

        <para>- TLB cachuji informace ve strankovacich tabulkach; alternativne

        se lze na strankovaci tabulky (ci ruzne hw rozsireni [e.g. VHPT, ppc32

        hw hash table]) divat jako na velke TLB</para>

        <para>- pri modifikaci mapovani nebo odstraneni mapovani ze

        strankovacich tabulek je potreba zajistit konsistenci TLB a techto

        tabulek; nutne delat na vsech CPU; na to mame zjednodusenou verzi TLB

        shootdown mechanismu; je to variace na algoritmus popsany zde: D.

        Black et al., "Translation Lookaside Buffer Consistency: A Software

        Approach," Proc. Third Int'l Conf. Architectural Support for

        Programming Languages and Operating Systems, 1989, pp. 113-122.</para>

        <para>- nutno poznamenat, ze existuji odlehcenejsi verze TLB shootdown

        algoritmu</para>

      </section>

    </section>