| 24,10 → 24,9 |
|---|
| Allowing, in general, to load and execute two programs that are linked on the same address without complicated relocations. |
| </listitem> |
| </itemizedlist></para> |
| |
| |
| <para><!-- |
| |
| <para><!-- |
| |
| TLB shootdown ASID/ASID:PAGE/ALL. |
| TLB shootdown requests can come in asynchroniously |
| so there is a cache of TLB shootdown requests. Upon cache overflow TLB shootdown ALL is executed |
| 43,23 → 42,19 |
|---|
| </section> |
| |
| <section> |
| |
| |
| <title>Paging</title> |
| |
| <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 course). 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 |
| frames (same sized as a page, of course). 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 |
| 66,11 → 61,11 |
|---|
| 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> |
| |
| <para>- pouzivame vypadky stranky k alokaci ramcu on-demand v ramci as_area - na architekturach, ktere to podporuji, podporujeme non-exec stranky </para> |
| <para>- pouzivame vypadky stranky k alokaci ramcu on-demand v ramci |
| as_area - na architekturach, ktere to podporuji, podporujeme non-exec |
| stranky</para> |
| </section> |
| |
| <section> |
| 79,15 → 74,11 |
|---|
| <section> |
| <title>Address spaces and areas</title> |
| |
| <para> |
| |
| - adresovy prostor se sklada z tzv. address space areas |
| <para>- adresovy prostor se sklada z tzv. address space areas |
| usporadanych v B+stromu; tyto areas popisuji vyuzivane casti |
| adresoveho prostoru patrici do user address space. Kazda cast je dana |
| svoji bazovou adresou, velikosti a flagy (rwx/dd). |
| svoji bazovou adresou, velikosti a flagy (rwx/dd).</para> |
| |
| </para> |
| |
| <para>- uzivatelske thready maji moznost manipulovat se svym adresovym |
| prostorem (vytvaret/resizovat/sdilet) as_areas pomoci syscallu</para> |
| </section> |
| 116,9 → 107,6 |
|---|
| a neni ani nijak osetrena. Tim padem plati, ze kazdy task ma vlastni |
| adresovy prostor</para> |
| </section> |
| |
| |
| |
| </section> |
| |
| <section> |
| 221,6 → 209,16 |
|---|
| <section id="frame_allocator"> |
| <title>Frame allocator</title> |
| |
| <para><mediaobject id="frame_alloc"> |
| <imageobject role="html"> |
| <imagedata fileref="images/frame_alloc.png" format="PNG" /> |
| </imageobject> |
| |
| <imageobject role="fop"> |
| <imagedata fileref="images.vector/frame_alloc.svg" format="SVG" /> |
| </imageobject> |
| </mediaobject></para> |
| |
| <formalpara> |
| <title>Overview</title> |
| |
| 262,6 → 260,16 |
|---|
| <section> |
| <title>Overview</title> |
| |
| <para><mediaobject id="buddy_alloc"> |
| <imageobject role="html"> |
| <imagedata fileref="images/buddy_alloc.png" format="PNG" /> |
| </imageobject> |
| |
| <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 |
| sized naturally aligned blocks. These blocks are organized in an array |
| of lists in which list with index i contains all unallocated blocks of |
| 301,8 → 309,8 |
|---|
| implementation of this interface, the buddy allocator can use |
| specialized external functions to find 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 <link |
| linkend="???">HelenOS Generic Kernel Reference Manual</link>.</para> |
| available. For precize documentation of this interface, refer to |
| <emphasis>"HelenOS Generic Kernel Reference Manual"</emphasis>.</para> |
| |
| <formalpara> |
| <title>Data organization</title> |
| 394,6 → 402,16 |
|---|
| <section> |
| <title>Implementation</title> |
| |
| <para><mediaobject id="slab_alloc"> |
| <imageobject role="html"> |
| <imagedata fileref="images/slab_alloc.png" format="PNG" /> |
| </imageobject> |
| |
| <imageobject role="fop"> |
| <imagedata fileref="images.vector/slab_alloc.svg" format="SVG" /> |
| </imageobject> |
| </mediaobject></para> |
| |
| <para>The SLAB allocator is closely modelled after <ulink |
| url="http://www.usenix.org/events/usenix01/full_papers/bonwick/bonwick_html/"> |
| OpenSolaris SLAB allocator by Jeff Bonwick and Jonathan Adams </ulink> |