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 |