← Back to branch summary

~vojtech-horky/helenos/numa

« back to all changes in this revision

Viewing changes to kernel/doc/mm

  • Committer: Martin Decky
  • Date: 2009-08-04 11:19:19 UTC
  • Revision ID: martin@uranus.dsrg.hide.ms.mff.cuni.cz-20090804111919-evyclddlr3v5lhmp
Initial import

Show diffs side-by-side

added added

removed removed

Lines of Context:
kernel/doc/mm
 
1
Memory management
 
2
=================
 
3
 
 
4
1. Virtual Address Translation
 
5
 
 
6
1.1 Hierarchical 4-level per address space page tables
 
7
 
 
8
SPARTAN kernel deploys generic interface for 4-level page tables for these
 
9
architectures: amd64, arm32, ia32, mips32 and ppc32. In this setting, page
 
10
tables are hierarchical and are not shared by address spaces (i.e. one set of
 
11
page tables per address space).
 
12
 
 
13
 
 
14
 VADDR
 
15
 +-----------------------------------------------------------------------------+
 
16
 |   PTL0_INDEX  |   PTL1_INDEX   |   PTL2_INDEX   |   PTL3_INDEX   |   OFFSET |
 
17
 +-----------------------------------------------------------------------------+
 
18
 
 
19
 
 
20
 PTL0                   PTL1                   PTL2                   PTL3
 
21
 +--------+             +--------+             +--------+             +--------+
 
22
 |        |             |        |             |  PTL3  | -----\      |        |
 
23
 |        |             |        |             +--------+      |      |        |
 
24
 |        |             +--------+             |        |      |      |        |
 
25
 |        |             |  PTL2  | -----\      |        |      |      |        |
 
26
 |        |             +--------+      |      |        |      |      |        |
 
27
 |        |             |        |      |      |        |      |      +--------+
 
28
 +--------+             |        |      |      |        |      |      | FRAME  |
 
29
 |  PTL1  | -----\      |        |      |      |        |      |      +--------+
 
30
 +--------+      |      |        |      |      |        |      |      |        |
 
31
 |        |      |      |        |      |      |        |      |      |        |
 
32
 |        |      |      |        |      |      |        |      |      |        |
 
33
 +--------+      \----> +--------+      \----> +--------+      \----> +--------+
 
34
     ^
 
35
     |
 
36
     |
 
37
 +--------+
 
38
 |  PTL0  |
 
39
 +--------+
 
40
 
 
41
 
 
42
PTL0            Page Table Level 0 (Page Directory)
 
43
PTL1            Page Table Level 1
 
44
PTL2            Page Table Level 2
 
45
PTL3            Page Table Level 3
 
46
 
 
47
PTL0_INDEX      Index into PTL0
 
48
PTL1_INDEX      Index into PTL1
 
49
PTL2_INDEX      Index into PTL2
 
50
PTL3_INDEX      Index into PTL3
 
51
 
 
52
VADDR           Virtual address for which mapping is looked up
 
53
FRAME           Physical address of memory frame to which VADDR is mapped
 
54
 
 
55
 
 
56
On architectures whose hardware has fewer levels, PTL2 and, if need be, PTL1 are
 
57
left out. TLB-only architectures are to define custom format for software page
 
58
tables.
 
59
 
 
60
1.2 Single global page hash table
 
61
 
 
62
Generic page hash table interface is deployed on 64-bit architectures without
 
63
implied hardware support for hierarchical page tables, i.e. ia64 and sparc64.
 
64
There is only one global page hash table in the system shared by all address
 
65
spaces.
 
66
 
 
67
 
 
68
2. Memory allocators
 
69
 
 
70
2.1 General allocator
 
71
 
 
72
'malloc' function accepts flags as a second argument. The flags are directly
 
73
passed to the underlying frame_alloc function. 
 
74
 
 
75
1) If the flags parameter contains FRAME_ATOMIC, the allocator will not sleep.
 
76
   The allocator CAN return NULL, when memory is not directly available.
 
77
   The caller MUST check if NULL was not returned
 
78
 
 
79
2) If the flags parameter does not contain FRAME_ATOMIC, the allocator
 
80
   will never return NULL, but it CAN sleep indefinitely. The caller
 
81
   does not have to check the return value.
 
82
 
 
83
3) The maximum size that can be allocated using malloc is 256K
 
84
 
 
85
Rules 1) and 2) apply to slab_alloc as well. Using SLAB allocator
 
86
to allocate too large values is not recommended.
 
87