| 38,8 → 38,8 |
|---|
| rather low. Moreover, most architectures merge all zones into |
| one.</para> |
| |
| <para>For each physical memory frame found in a zone, there is a frame |
| structure that contains number of references and data used by buddy |
| <para>Every physical memory frame in a zone, is described by a structure |
| that contains number of references and other data used by buddy |
| system.</para> |
| </section> |
| |
| 53,7 → 53,7 |
|---|
| <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 |
| within a context of some frame zone. In order to carry out the |
| within a context of a particular frame zone. In order to carry out the |
| allocation requests, the frame allocator is tightly integrated with the |
| buddy system belonging to the zone. The frame allocator is also |
| responsible for updating information about the number of free and busy |
| 280,8 → 280,8 |
|---|
| <para><emphasis>Step 1.</emphasis> When an allocation request |
| comes, the slab allocator checks availability of memory in the |
| current magazine of the local processor magazine cache. If the |
| available memory is there, the allocator just pops the magazine |
| and returns pointer to the object.</para> |
| available memory is there, the allocator just pops the object from |
| magazine and returns it.</para> |
| |
| <para><emphasis>Step 2.</emphasis> If the current magazine in the |
| processor magazine cache is empty, the allocator will attempt to |
| 306,7 → 306,7 |
|---|
| |
| <para><emphasis>Step 1.</emphasis> During a deallocation request, |
| the slab allocator checks if the current magazine of the local |
| processor magazine cache is not full. If yes, the pointer to the |
| processor magazine cache is not full. If it is, the pointer to the |
| objects is just pushed into the magazine and the algorithm |
| returns.</para> |
| |
| 318,8 → 318,15 |
|---|
| |
| <para><emphasis>Step 3.</emphasis> Now the allocator is in the |
| situation when both magazines in the processor magazine cache are |
| full. The allocator moves one magazine to the shared list of full |
| magazines. The algoritm continues with Step 1.</para> |
| full. The allocator tries to allocate a new empty magazine and |
| flush one of the full magazines to the shared list of full |
| magazines. If it is successfull, the algoritm continues with Step |
| 1.</para> |
| |
| <para><emphasis>Step 4. </emphasis>In case of low memory condition |
| when the allocation of empty magazine fails, the object is moved |
| directly into slab. In the worst case object deallocation does not |
| need to allocate any additional memory.</para> |
| </formalpara> |
| </section> |
| </section> |
| 403,22 → 410,20 |
|---|
| |
| <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 |
| from the old address space must be flushed, which can create certain |
| uncessary overhead during the task switching. To avoid this, some |
| architectures have capability to segregate different address spaces on |
| hardware level introducing the address space identifier as a part of |
| TLB record, telling the virtual address space translation unit to |
| which address space this record is applicable.</para> |
| <para>Every task in the operating system has it's own view of the |
| virtual memory. When performing context switch between different |
| tasks, the kernel must switch the address space mapping as well. As |
| modern processors perform very aggressive caching of virtual mappings, |
| flushing the complete TLB on every context switch would be very |
| inefficient. To avoid such performance penalty, some architectures |
| introduce an address space identifier, which allows storing several |
| different mappings inside TLB.</para> |
| |
| <para>HelenOS kernel can take advantage of this hardware supported |
| identifier by having an ASID abstraction which is somehow related to |
| the corresponding architecture identifier. I.e. on ia64 kernel ASID is |
| derived from RID (region identifier) and on the mips32 kernel ASID is |
| actually the hardware identifier. As expected, this ASID information |
| record is the part of <emphasis>as_t</emphasis> structure.</para> |
| <para>HelenOS kernel can take advantage of this hardware support by |
| having an ASID abstraction. I.e. on ia64 kernel ASID is derived from |
| RID (region identifier) and on the mips32 kernel ASID is actually the |
| hardware identifier. As expected, this ASID information record is the |
| part of <emphasis>as_t</emphasis> structure.</para> |
| |
| <para>Due to the hardware limitations, hardware ASID has limited |
| length from 8 bits on ia64 to 24 bits on mips32, which makes it |