Subversion Repositories HelenOS-doc

Compare Revisions

Ignore whitespace Rev 75 → Rev 76

/design/trunk/src/ch_memory_management.xml
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
/design/trunk/src/ch_scheduling.xml
37,12 → 37,12
</listitem>
</itemizedlist>
 
<para>The most narrow sence refers to the the synchronous register
<para>The most narrow sense refers to the the synchronous register
context. It includes all the preserved registers as defined by the
architecture. To highlight some, the program counter and stack pointer
take part in the synchronous register context. These are the registers
that must be preserved across a procedure call and during synchronous
context switches.</para>
take part in the synchronous register context. These registers must be
preserved across a procedure call and during synchronous context
switches.</para>
 
<para>The next type of the context understood by the kernel is the
asynchronous register context. On an interrupt, the interrupted execution
255,10 → 255,10
<para>Normally, for the sake of cache locality, threads are scheduled on
one of the processors and don't leave it. Nevertheless, a situation in
which one processor is heavily overloaded while others sit idle can
occur. HelenOS deploys special kernel threads to help to mitigate this
occur. HelenOS deploys special kernel threads to help mitigate this
problem. Each processor is associated with one load balancing thread
called <code>kcpulb</code> that wakes up regularily to see whether its
processor is underbalanced or not. If yes, the thread attempts to
called <code>kcpulb</code> that wakes up regularly to see whether its
processor is underbalanced or not. If it is, the thread attempts to
migrate threads from other overloaded processors to its own processor's
run queues. When the job is done or there is no need for load balancing,
the thread goes to sleep.</para>