1 |
physmem |
Introduction |
2 |
======= |
============ |
3 |
|
|
4 |
For now, this is only a small dummy program, not the real physical |
physmem is the physical memory manager. It has nothing to do with |
5 |
memory server. |
virtual memory management; that is the domain of the applications |
6 |
|
themselves. |
7 |
|
|
8 |
|
The physical memory server provides three different resources: memory |
9 |
|
control capabilities, containers and frames. |
10 |
|
|
11 |
|
Memory Control Ports |
12 |
|
-------------------- |
13 |
|
|
14 |
|
Memory control capabilities hold the right to guarantee a number of |
15 |
|
frames. A memory control capability may be split. If a memory |
16 |
|
control capability, A, holds the right to 100 frames and a new memory |
17 |
|
control capability, B, is split from it to hold 10 frames, after the |
18 |
|
operation, A guarantees 90 frames and B 10. |
19 |
|
|
20 |
|
In this scenario, the B is considered the child of the A. If B is |
21 |
|
destroyed it (as well as any memory control ports which have been |
22 |
|
split from it) are absorbed back into A and any containers and frames |
23 |
|
allocated using it are implicit deallocated. |
24 |
|
|
25 |
|
When a task is started, the starter may split its memory control |
26 |
|
capability and give a copy of the new capability to the new task. |
27 |
|
Alternatively, two tasks may share a memory control capability. |
28 |
|
|
29 |
|
In the former scenario, when the starter wants to terminate the child, |
30 |
|
it may reclaim the frames by destroying the memory control capability. |
31 |
|
|
32 |
|
Containers |
33 |
|
---------- |
34 |
|
|
35 |
|
physmem will allocate a container given a memory control capability. |
36 |
|
When a frame is allocated into the container, the memory control |
37 |
|
capability from which it was created it charged. |
38 |
|
|
39 |
|
A container represents a name space. Valid container names (integers) |
40 |
|
refer to bytes in a frame. The contents of container are not directly |
41 |
|
accessible to tasks. A task must first map the contents of a |
42 |
|
container into its virtual address space. |
43 |
|
|
44 |
|
Containers are used to share memory with other processes. For |
45 |
|
instance, in the case of a client of a filesystem. The client creates |
46 |
|
a container with a number of pages and sends it to the filesystem |
47 |
|
which reads the data from backing store into the memory. Since the |
48 |
|
client may not be able to trust the server to not steal the physical |
49 |
|
frames, the client must not give the capability to it. Hence, a |
50 |
|
weaker capability is provided which allows a server limited access to |
51 |
|
a container. |
52 |
|
|
53 |
|
Frames |
54 |
|
------ |
55 |
|
|
56 |
|
Frames are allocated in containers at particular addresses. A client |
57 |
|
may allocate any number of base page size frames at once (assuming |
58 |
|
that there is enough credit in the memory control capability). |
59 |
|
Internally, this range will immediately be converted to power of 2 |
60 |
|
frames. |
61 |
|
|
62 |
|
Once allocated, a task may request a map of a frame from the physical |
63 |
|
memory server. Maps are not guaranteed to be persistent: physmem may |
64 |
|
rearrange physical memory to defragment it or to clear space in a |
65 |
|
special zone (for instance, for DMA). Frames, may, however, be pinned |
66 |
|
in place for a limited amount of time. |
67 |
|
|
68 |
|
Frames are multiplexed as well as shared across multiple tasks, it is |
69 |
|
useful to reallocate frames in place. In this way, data structures |
70 |
|
are not torn down just to be immediately recreated and gratuitous COWs |
71 |
|
are not performed. container_release disassociates frames in a region |
72 |
|
with any shared frames. |
73 |
|
|
74 |
|
When a frame is deallocated, physmem may not immediately unmap it from |
75 |
|
the client where it is safe to do so (i.e. without leaking information |
76 |
|
or giving a task access which it should not have). This is useful in |
77 |
|
the case of highly shared read-only memory, e.g. shared libraries. |
78 |
|
|
79 |
|
Data Structures |
80 |
|
=============== |
81 |
|
|
82 |
|
Given a container capability, a `struct container' can be derived from |
83 |
|
it. A container contains a btree of frame entries keyed by their |
84 |
|
start index and size. |
85 |
|
|
86 |
|
A frame entry points to a `struct frame'. Exactly one frame entry |
87 |
|
exists for each mapping of a frame. Hence, the frame entry is |
88 |
|
per-mapping state and a frame is per-frame state. Frames are |
89 |
|
reference counted. |