Re: L4Env

[Espen Skoglund]

[Niels Möller]
> Lars Reuther <address@hidden> writes:
>> Our memory management consists of two main elements, dataspace
>> managers and region mappers. Dataspaces are container for any kind
>> of memory (files, anonymous memory, ...). They are managed by
>> dataspace managers (e.g. file systems, anonymous memory managers,
>> ...). Dataspaces can be attached to regions of the address space of
>> a L4 task.

>> Region mappers are pager threads, usually we use one region mapper
>> in each L4 task which is the pager for all other threads of that
>> task. The region mapper doesn't resolve the pagefault itself,
>> instead it looks up the dataspace which is attached to the
>> pagefault address and calls the dataspace manager which manages
>> that dataspace to map the appropriate page.

> Sounds cute. But one question: What happes if the task is completely
> swapped out? I.e. when none of the pages in it's dataspaces are
> assigned to physical management? How can it get swapped in again? I
> guess you're keeping the code and data needed by the pager thread in
> physical memory, somehow. The code pages can be shared between
> tasks, I guess.

If the task is completely swapped out the pager which swapped the task
out should also inform the system not to schedule the task.

If the task IS scheduled again it will immidiately pagefault and a
pagefault IPC will be sent to the region mapper.  The region mapper
will also immediately pagefault (its code might be in memory because
it can be shared by other tasks, but the data structures keeping track
of dataspaces can not).  The pager for the region mapper can then take
appropriate measures to page in the data structrures again.  Once the
datastructures are there (or if they never were paged out in the first
place) the region mapped can resolve the pagefaults.  Of course,
swapping out a task without also ensuring that the task is not
immediately scheduled is not the smartests of things to do.

        eSk