Memory mapping

Adam 'WeirdArms' Wiggins awiggins at cse.unsw.EDU.AU
Mon Dec 8 00:13:59 CET 2003

	Just a few clarifications, at least I hope I clarify things ;)

On Mon, 7 Dec 2003, Jonathan S. Shapiro wrote:

> So:
> The key differences between the L4 mapping state and the EROS-NG (next
> generation) mapping state may be described as follows:
>   + In L4, the only important state is the state recorded in
>     the mapping database. This state is a cache, and applications
>     are required to be able to reconstruct their own mapping
>     state on demand.

	The mapping database is a cache only in the sence that at any time
a higher level pager can revoke a mapping from an application or
lower-level papers. In the current model the kernel 'never' throws away

>     Page fault handlers can be injected at any arbitrary GPT.
> There seem to be advantages and disadvantages to each design.
> 1. Cost of mapping:
> I believe the the correct way to measure the cost of a map operation is
> to include all of the costs necessary to actually get a valid PTE into
> the recipient address space.
> * L4 Map
> The dominant cost in the L4 map operation is the cost to build the
> necessary mapping DB entries in the kernel. PTEs are copied
> aggressively, so there are usually no further hardware page faults
> needed to load them when the recipient starts running.
> In addition to the kernel-level map operation, the recipient task must
> record the incoming mapping in some per-task database. This database
> essentially duplicates the state in the kernel, though my guess is that
> it can be accomplished via a region-based recording scheme in the usual
> cases (that is: I record that X bytes from File Y got mapped starting at
> address A, and that faults in this region should be recovered by making
> a request to thread-id T). It is not clear to me what the practical
> overhead of this additional tracking is.

	The mapping database is not per-task. There is a single mapping
database in the kernel and it consists of a mapping tree per physical
frame of memory.
	In fact, in some of the implementations the mapping database nodes
are all stored in page tables leaf nodes.

> Unless something has changed in a way that I have failed to understand,
> L4 does not provide a means to share page tables across more than one
> task.

	L4 does not explicitly export any concept of sharing page table
sub-tree's but you can build this knowledge from the map/grant/unmap
primitives. There have been proposals floated to make sharing explicit (ie
the Link operation) and via mapping hints.

> Random Comments:
> It appears to me that there are peculiar boundary conditions implicit in
> the L4 design: if the very last page of a process is paged out, I am not
> sure how its pager thread runs, because I do not understand what memory
> that pager thread references in order to initiate instructions or store
> temporary data. I suspect that the solution is that the pager thread in
> turn specifies a pager thread (which I will call the meta-pager), and
> the meta-pager arranges to page enough state back in that the pager
> thread can make progress.

	The paper thread need not be in the same address space as the
thread it is paging so as you point out if all threads in an address-space
(bar one) use an address-space local thread as their pager, then you could
speficy an address-space external thread as that thread's pager.

> Probably this all seems perfectly obvious to people who are familiar
> with L4. I find it confusing that every process must have two threads or
> must delegate mapping management to a third-party task.

	Pagers are not specified per address space. They are specified per
thread. No third party task would be required if by some estabilished
protocol, the minimal set of pages an address-space-local pager needed
were pinned in memory.

	Cheers, Adam

Adam "WeirdArms" Wiggins           School of Computer Sci. & Eng.
PhD Student                        The University of NSW
Phone: +61 2 9385 7359             UNSW SYDNEY NSW 2052, Australia
Fax:   +61 2 9385 7942   

More information about the l4-hackers mailing list