Commit | Line | Data |
---|---|---|
eeb8a642 | 1 | .. _highmem: |
d65bfacb | 2 | |
eeb8a642 MR |
3 | ==================== |
4 | High Memory Handling | |
5 | ==================== | |
d65bfacb PZ |
6 | |
7 | By: Peter Zijlstra <a.p.zijlstra@chello.nl> | |
8 | ||
eeb8a642 | 9 | .. contents:: :local: |
d65bfacb | 10 | |
eeb8a642 | 11 | What Is High Memory? |
d65bfacb PZ |
12 | ==================== |
13 | ||
14 | High memory (highmem) is used when the size of physical memory approaches or | |
15 | exceeds the maximum size of virtual memory. At that point it becomes | |
16 | impossible for the kernel to keep all of the available physical memory mapped | |
17 | at all times. This means the kernel needs to start using temporary mappings of | |
18 | the pieces of physical memory that it wants to access. | |
19 | ||
20 | The part of (physical) memory not covered by a permanent mapping is what we | |
21 | refer to as 'highmem'. There are various architecture dependent constraints on | |
22 | where exactly that border lies. | |
23 | ||
24 | In the i386 arch, for example, we choose to map the kernel into every process's | |
25 | VM space so that we don't have to pay the full TLB invalidation costs for | |
26 | kernel entry/exit. This means the available virtual memory space (4GiB on | |
27 | i386) has to be divided between user and kernel space. | |
28 | ||
29 | The traditional split for architectures using this approach is 3:1, 3GiB for | |
eeb8a642 | 30 | userspace and the top 1GiB for kernel space:: |
d65bfacb PZ |
31 | |
32 | +--------+ 0xffffffff | |
33 | | Kernel | | |
34 | +--------+ 0xc0000000 | |
35 | | | | |
36 | | User | | |
37 | | | | |
38 | +--------+ 0x00000000 | |
39 | ||
40 | This means that the kernel can at most map 1GiB of physical memory at any one | |
41 | time, but because we need virtual address space for other things - including | |
42 | temporary maps to access the rest of the physical memory - the actual direct | |
43 | map will typically be less (usually around ~896MiB). | |
44 | ||
45 | Other architectures that have mm context tagged TLBs can have separate kernel | |
46 | and user maps. Some hardware (like some ARMs), however, have limited virtual | |
47 | space when they use mm context tags. | |
48 | ||
49 | ||
eeb8a642 | 50 | Temporary Virtual Mappings |
d65bfacb PZ |
51 | ========================== |
52 | ||
110bf7a5 FDF |
53 | The kernel contains several ways of creating temporary mappings. The following |
54 | list shows them in order of preference of use. | |
d65bfacb | 55 | |
110bf7a5 FDF |
56 | * kmap_local_page(). This function is used to require short term mappings. |
57 | It can be invoked from any context (including interrupts) but the mappings | |
58 | can only be used in the context which acquired them. | |
59 | ||
60 | This function should be preferred, where feasible, over all the others. | |
d65bfacb | 61 | |
110bf7a5 FDF |
62 | These mappings are thread-local and CPU-local, meaning that the mapping |
63 | can only be accessed from within this thread and the thread is bound the | |
64 | CPU while the mapping is active. Even if the thread is preempted (since | |
65 | preemption is never disabled by the function) the CPU can not be | |
66 | unplugged from the system via CPU-hotplug until the mapping is disposed. | |
67 | ||
68 | It's valid to take pagefaults in a local kmap region, unless the context | |
69 | in which the local mapping is acquired does not allow it for other reasons. | |
70 | ||
71 | kmap_local_page() always returns a valid virtual address and it is assumed | |
72 | that kunmap_local() will never fail. | |
73 | ||
74 | Nesting kmap_local_page() and kmap_atomic() mappings is allowed to a certain | |
75 | extent (up to KMAP_TYPE_NR) but their invocations have to be strictly ordered | |
76 | because the map implementation is stack based. See kmap_local_page() kdocs | |
77 | (included in the "Functions" section) for details on how to manage nested | |
78 | mappings. | |
d65bfacb | 79 | |
eeb8a642 MR |
80 | * kmap_atomic(). This permits a very short duration mapping of a single |
81 | page. Since the mapping is restricted to the CPU that issued it, it | |
82 | performs well, but the issuing task is therefore required to stay on that | |
83 | CPU until it has finished, lest some other task displace its mappings. | |
d65bfacb | 84 | |
110bf7a5 FDF |
85 | kmap_atomic() may also be used by interrupt contexts, since it does not |
86 | sleep and the callers too may not sleep until after kunmap_atomic() is | |
87 | called. | |
88 | ||
89 | Each call of kmap_atomic() in the kernel creates a non-preemptible section | |
90 | and disable pagefaults. This could be a source of unwanted latency. Therefore | |
91 | users should prefer kmap_local_page() instead of kmap_atomic(). | |
d65bfacb | 92 | |
110bf7a5 FDF |
93 | It is assumed that k[un]map_atomic() won't fail. |
94 | ||
95 | * kmap(). This should be used to make short duration mapping of a single | |
96 | page with no restrictions on preemption or migration. It comes with an | |
97 | overhead as mapping space is restricted and protected by a global lock | |
98 | for synchronization. When mapping is no longer needed, the address that | |
99 | the page was mapped to must be released with kunmap(). | |
100 | ||
101 | Mapping changes must be propagated across all the CPUs. kmap() also | |
102 | requires global TLB invalidation when the kmap's pool wraps and it might | |
103 | block when the mapping space is fully utilized until a slot becomes | |
104 | available. Therefore, kmap() is only callable from preemptible context. | |
105 | ||
106 | All the above work is necessary if a mapping must last for a relatively | |
107 | long time but the bulk of high-memory mappings in the kernel are | |
108 | short-lived and only used in one place. This means that the cost of | |
109 | kmap() is mostly wasted in such cases. kmap() was not intended for long | |
110 | term mappings but it has morphed in that direction and its use is | |
111 | strongly discouraged in newer code and the set of the preceding functions | |
112 | should be preferred. | |
113 | ||
114 | On 64-bit systems, calls to kmap_local_page(), kmap_atomic() and kmap() have | |
115 | no real work to do because a 64-bit address space is more than sufficient to | |
116 | address all the physical memory whose pages are permanently mapped. | |
117 | ||
118 | * vmap(). This can be used to make a long duration mapping of multiple | |
119 | physical pages into a contiguous virtual space. It needs global | |
120 | synchronization to unmap. | |
d65bfacb PZ |
121 | |
122 | ||
eeb8a642 | 123 | Cost of Temporary Mappings |
d65bfacb PZ |
124 | ========================== |
125 | ||
126 | The cost of creating temporary mappings can be quite high. The arch has to | |
127 | manipulate the kernel's page tables, the data TLB and/or the MMU's registers. | |
128 | ||
129 | If CONFIG_HIGHMEM is not set, then the kernel will try and create a mapping | |
130 | simply with a bit of arithmetic that will convert the page struct address into | |
131 | a pointer to the page contents rather than juggling mappings about. In such a | |
132 | case, the unmap operation may be a null operation. | |
133 | ||
134 | If CONFIG_MMU is not set, then there can be no temporary mappings and no | |
135 | highmem. In such a case, the arithmetic approach will also be used. | |
136 | ||
137 | ||
d65bfacb PZ |
138 | i386 PAE |
139 | ======== | |
140 | ||
141 | The i386 arch, under some circumstances, will permit you to stick up to 64GiB | |
142 | of RAM into your 32-bit machine. This has a number of consequences: | |
143 | ||
eeb8a642 MR |
144 | * Linux needs a page-frame structure for each page in the system and the |
145 | pageframes need to live in the permanent mapping, which means: | |
d65bfacb | 146 | |
eeb8a642 MR |
147 | * you can have 896M/sizeof(struct page) page-frames at most; with struct |
148 | page being 32-bytes that would end up being something in the order of 112G | |
149 | worth of pages; the kernel, however, needs to store more than just | |
150 | page-frames in that memory... | |
d65bfacb | 151 | |
eeb8a642 MR |
152 | * PAE makes your page tables larger - which slows the system down as more |
153 | data has to be accessed to traverse in TLB fills and the like. One | |
154 | advantage is that PAE has more PTE bits and can provide advanced features | |
155 | like NX and PAT. | |
d65bfacb PZ |
156 | |
157 | The general recommendation is that you don't use more than 8GiB on a 32-bit | |
158 | machine - although more might work for you and your workload, you're pretty | |
159 | much on your own - don't expect kernel developers to really care much if things | |
160 | come apart. | |
174270c2 FDF |
161 | |
162 | ||
163 | Functions | |
164 | ========= | |
165 | ||
166 | .. kernel-doc:: include/linux/highmem.h | |
167 | .. kernel-doc:: include/linux/highmem-internal.h |