| 60,12 → 60,6 |
|---|
| 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> |
| |
| <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> |
| 72,40 → 66,77 |
|---|
| <title>Address spaces</title> |
| |
| <section> |
| <title>Address spaces and areas</title> |
| <title>Address space areas</title> |
| |
| <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).</para> |
| <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 is contains.</para> |
| |
| <para>- uzivatelske thready maji moznost manipulovat se svym adresovym |
| prostorem (vytvaret/resizovat/sdilet) as_areas pomoci syscallu</para> |
| <para>Address space area also has special flags, that define behaviour |
| and permissions on the particular area. <itemizedlist> |
| <listitem> |
| |
| |
| <emphasis>AS_AREA_READ</emphasis> |
| |
| flag indicates reading permission. |
| </listitem> |
| |
| <listitem> |
| |
| |
| <emphasis>AS_AREA_WRITE</emphasis> |
| |
| flag indicates writing permission. |
| </listitem> |
| |
| <listitem> |
| |
| |
| <emphasis>AS_AREA_EXEC</emphasis> |
| |
| flag indicates code execution permission. Some architectures do not support execution persmission restriction. In this case this flag has no effect. |
| </listitem> |
| |
| <listitem> |
| |
| |
| <emphasis>AS_AREA_DEVICE</emphasis> |
| |
| marks area as mapped to the device memory. |
| </listitem> |
| </itemizedlist></para> |
| |
| <para>Kernel provides possibility tasks create/expand/shrink/share its |
| address space via the set of syscalls.</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>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 mappings from the old address |
| space should be flushed, which can create certain uncessary |
| overhead.</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>To avoid this, some architectures have capability to segregate |
| different address spaces on HW level introducing the ASID (address |
| space ID). On those architectures each TLB record contains an address |
| space identifier, that tells to which address space this record is |
| applicable.</para> |
| |
| <para>- na vsech arch. plati, ze asidu je mnohem mene, nez teoreticky |
| pocet soucasne bezicich tasku ~ adresovych prostoru, takze je |
| implementovan mechanismus, ktery umoznuje jednomu adresovemu prostoru |
| ASID odebrat a pridelit ho jinemu</para> |
| <para>HelenOS kernel can take advantage of this hardware supported |
| identifier by having an ASID abstraction which is connected to the |
| corresponding architecture identifier. I.e. on ia64 kernel ASID is |
| built from RID (region identifier) and on the mips32 kernel ASID is |
| actually the hardware identifier.</para> |
| |
| <para>- vztah task ~ adresovy prostor: teoreticky existuje moznost, ze |
| 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> |
| <para>Due to the hardware limitations ASID has limited length from 8 |
| bits on ia64 to 24 bits on mips32, which makes it impossible to use as |
| unique address space identifier for all tasks running in the system. |
| In such situations special ASID stealing algoritm is used, which takes |
| ASID from inactive task and assigns it to the active task.</para> |
| </section> |
| </section> |
| |
| 145,7 → 176,8 |
|---|
| |
| <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> |
| genericke hash table s oddelenymi collision chains. ASID support is |
| required to use global hash tables.</para> |
| </formalpara> |
| |
| <para>Thanks to the abstract paging interface, there is possibility |
| 154,7 → 186,7 |
|---|
| </section> |
| |
| <section id="tlb"> |
| <title>Translation Lookaside buffer</title> |
| <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 |
| 169,9 → 201,19 |
|---|
| Programming Languages and Operating Systems, 1989, pp. 113-122.</para> |
| |
| <para>- nutno poznamenat, ze existuji odlehcenejsi verze TLB shootdown |
| algoritmu</para> |
| algoritm</para> |
| </section> |
| </section> |
| |
| <section> |
| <title>---</title> |
| |
| <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> |
| </section> |
| </section> |
| |
| <!-- End of VM --> |
| 276,18 → 318,18 |
|---|
| contains all unallocated blocks of size |
| <mathphrase>2<superscript>i</superscript></mathphrase>. The index i is |
| called the order of block. Should there be two adjacent equally sized |
| blocks in the list i<mathphrase> </mathphrase>(i.e. buddies), the |
| buddy allocator would coalesce them and put the resulting block in |
| list <mathphrase>i + 1</mathphrase>, provided that the resulting block |
| would be naturally aligned. Similarily, when the allocator is asked to |
| allocate a block of size |
| <mathphrase>2<superscript>i</superscript></mathphrase>, it first tries |
| to satisfy the request from the list with index i. If the request |
| cannot be satisfied (i.e. the list i is empty), the buddy allocator |
| will try to allocate and split a larger block from the list with index |
| i + 1. Both of these algorithms are recursive. The recursion ends |
| either when there are no blocks to coalesce in the former case or when |
| there are no blocks that can be split in the latter case.</para> |
| blocks in the list i<mathphrase />(i.e. buddies), the buddy allocator |
| would coalesce them and put the resulting block in list <mathphrase>i |
| + 1</mathphrase>, provided that the resulting block would be naturally |
| aligned. Similarily, when the allocator is asked to allocate a block |
| of size <mathphrase>2<superscript>i</superscript></mathphrase>, it |
| first tries to satisfy the request from the list with index i. If the |
| request cannot be satisfied (i.e. the list i is empty), the buddy |
| allocator will try to allocate and split a larger block from the list |
| with index i + 1. Both of these algorithms are recursive. The |
| recursion ends either when there are no blocks to coalesce in the |
| former case or when there are no blocks that can be split in the |
| latter case.</para> |
| |
| <!--graphic fileref="images/mm1.png" format="EPS" /--> |
| |
| 461,12 → 503,13 |
|---|
| magazine size boundary. LIFO order is enforced, which should avoid |
| fragmentation as much as possible.</para> |
| |
| <para>Another important entity of magazine layer is a full magazine |
| depot, that stores full magazines which are used by any of the CPU |
| magazine caches to reload active CPU magazine. Magazine depot can be |
| pre-filled with full magazines during initialization, but in current |
| implementation it is filled during object deallocation, when CPU |
| magazine becomes full.</para> |
| <para>Another important entity of magazine layer is the common full |
| magazine list (also called a depot), that stores full magazines that |
| may be used by any of the CPU magazine caches to reload active CPU |
| magazine. This list of magazines can be pre-filled with full |
| magazines during initialization, but in current implementation it is |
| filled during object deallocation, when CPU magazine becomes |
| full.</para> |
| |
| <para>Slab allocator control structures are allocated from special |
| slabs, that are marked by special flag, indicating that it should |