doebel at os.inf.tu-dresden.de
Sat Jan 15 19:15:00 CET 2011
> OK, but what if I want extend address space of a task
> how I can do this? And also, what is the default size
> for a address space for a task?
you need to distinguish two things here. Part one are the concepts
behind memory management, part two are the concrete implementations in
Fiasco.OC and the L4 runtime environment.
Let's start with the concepts.
When an application runs (e.g., because you just started it and it is
now trying to access its first instruction), it accesses memory. If
there is now mapping in the hardware page table, a page fault exception
is raised by the CPU. This ends up being handled by the kernel.
We do user-level memory management, which means that everything from
page fault handling to higher level concepts is done by applications
themselves instead of the kernel. Therefore, the kernel redirects the
page fault to a user-level page fault handler. The handler is just
another user-level thread, which then performs the real work of handling
a page fault, e.g., by mapping an already available range of memory
(e.g., a part of a file) to the faulting thread.
To do so, the handler needs to keep knowledge about how a client's
Now to the implementation:
* The Fiasco.OC kernel knows a page fault handler thread for each thread
in the system.
* The kernel uses IPC for sending the page fault message to the handler.
* The handler can map an arbitrary part from his own address space to
the client. We call such a part a "region".
* Mapping regions is done through IPC. To do so, the sender attaches a
special data type describing a memory region to the
IPC message. The kernel detects this and establishes a memory
mapping accordingly. This data type is called a "flexpage".
* In order to maintain a task's address space layout, every task has a
dedicated "region manager" thread. This thread acts as
the PF handler for all other threads in a task and maintains a
consistent view of the address space.
* In order to be able to construct the address space from regions of
different sources (e.g., the application binary coming from
a file system and anonymous memory coming from a memory manager), we
introduce another abstraction for describing
memory regions, called "data spaces".
This is the very short overview of memory management. More details can
for instance be found in our lecture on microkernel-based operating
systems, which's slides are available from
More information about the l4-hackers