]>
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 | 62 | These mappings are thread-local and CPU-local, meaning that the mapping |
a9e9c939 FDF |
63 | can only be accessed from within this thread and the thread is bound to the |
64 | CPU while the mapping is active. Although preemption is never disabled by | |
65 | this function, the CPU can not be unplugged from the system via | |
66 | CPU-hotplug until the mapping is disposed. | |
110bf7a5 FDF |
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 | ||
a9e9c939 FDF |
71 | As said, pagefaults and preemption are never disabled. There is no need to |
72 | disable preemption because, when context switches to a different task, the | |
73 | maps of the outgoing task are saved and those of the incoming one are | |
74 | restored. | |
75 | ||
110bf7a5 FDF |
76 | kmap_local_page() always returns a valid virtual address and it is assumed |
77 | that kunmap_local() will never fail. | |
78 | ||
516ea046 FDF |
79 | On CONFIG_HIGHMEM=n kernels and for low memory pages this returns the |
80 | virtual address of the direct mapping. Only real highmem pages are | |
81 | temporarily mapped. Therefore, users may call a plain page_address() | |
82 | for pages which are known to not come from ZONE_HIGHMEM. However, it is | |
83 | always safe to use kmap_local_page() / kunmap_local(). | |
84 | ||
6b3afe2e FDF |
85 | While it is significantly faster than kmap(), for the higmem case it |
86 | comes with restrictions about the pointers validity. Contrary to kmap() | |
87 | mappings, the local mappings are only valid in the context of the caller | |
88 | and cannot be handed to other contexts. This implies that users must | |
89 | be absolutely sure to keep the use of the return address local to the | |
90 | thread which mapped it. | |
91 | ||
84b86f60 FDF |
92 | Most code can be designed to use thread local mappings. User should |
93 | therefore try to design their code to avoid the use of kmap() by mapping | |
94 | pages in the same thread the address will be used and prefer | |
95 | kmap_local_page(). | |
96 | ||
110bf7a5 FDF |
97 | Nesting kmap_local_page() and kmap_atomic() mappings is allowed to a certain |
98 | extent (up to KMAP_TYPE_NR) but their invocations have to be strictly ordered | |
99 | because the map implementation is stack based. See kmap_local_page() kdocs | |
100 | (included in the "Functions" section) for details on how to manage nested | |
101 | mappings. | |
d65bfacb | 102 | |
eeb8a642 MR |
103 | * kmap_atomic(). This permits a very short duration mapping of a single |
104 | page. Since the mapping is restricted to the CPU that issued it, it | |
105 | performs well, but the issuing task is therefore required to stay on that | |
106 | CPU until it has finished, lest some other task displace its mappings. | |
d65bfacb | 107 | |
110bf7a5 FDF |
108 | kmap_atomic() may also be used by interrupt contexts, since it does not |
109 | sleep and the callers too may not sleep until after kunmap_atomic() is | |
110 | called. | |
111 | ||
112 | Each call of kmap_atomic() in the kernel creates a non-preemptible section | |
113 | and disable pagefaults. This could be a source of unwanted latency. Therefore | |
114 | users should prefer kmap_local_page() instead of kmap_atomic(). | |
d65bfacb | 115 | |
110bf7a5 FDF |
116 | It is assumed that k[un]map_atomic() won't fail. |
117 | ||
118 | * kmap(). This should be used to make short duration mapping of a single | |
119 | page with no restrictions on preemption or migration. It comes with an | |
120 | overhead as mapping space is restricted and protected by a global lock | |
121 | for synchronization. When mapping is no longer needed, the address that | |
122 | the page was mapped to must be released with kunmap(). | |
123 | ||
124 | Mapping changes must be propagated across all the CPUs. kmap() also | |
125 | requires global TLB invalidation when the kmap's pool wraps and it might | |
126 | block when the mapping space is fully utilized until a slot becomes | |
127 | available. Therefore, kmap() is only callable from preemptible context. | |
128 | ||
129 | All the above work is necessary if a mapping must last for a relatively | |
130 | long time but the bulk of high-memory mappings in the kernel are | |
131 | short-lived and only used in one place. This means that the cost of | |
132 | kmap() is mostly wasted in such cases. kmap() was not intended for long | |
133 | term mappings but it has morphed in that direction and its use is | |
134 | strongly discouraged in newer code and the set of the preceding functions | |
135 | should be preferred. | |
136 | ||
137 | On 64-bit systems, calls to kmap_local_page(), kmap_atomic() and kmap() have | |
138 | no real work to do because a 64-bit address space is more than sufficient to | |
139 | address all the physical memory whose pages are permanently mapped. | |
140 | ||
141 | * vmap(). This can be used to make a long duration mapping of multiple | |
142 | physical pages into a contiguous virtual space. It needs global | |
143 | synchronization to unmap. | |
d65bfacb PZ |
144 | |
145 | ||
eeb8a642 | 146 | Cost of Temporary Mappings |
d65bfacb PZ |
147 | ========================== |
148 | ||
149 | The cost of creating temporary mappings can be quite high. The arch has to | |
150 | manipulate the kernel's page tables, the data TLB and/or the MMU's registers. | |
151 | ||
152 | If CONFIG_HIGHMEM is not set, then the kernel will try and create a mapping | |
153 | simply with a bit of arithmetic that will convert the page struct address into | |
154 | a pointer to the page contents rather than juggling mappings about. In such a | |
155 | case, the unmap operation may be a null operation. | |
156 | ||
157 | If CONFIG_MMU is not set, then there can be no temporary mappings and no | |
158 | highmem. In such a case, the arithmetic approach will also be used. | |
159 | ||
160 | ||
d65bfacb PZ |
161 | i386 PAE |
162 | ======== | |
163 | ||
164 | The i386 arch, under some circumstances, will permit you to stick up to 64GiB | |
165 | of RAM into your 32-bit machine. This has a number of consequences: | |
166 | ||
eeb8a642 MR |
167 | * Linux needs a page-frame structure for each page in the system and the |
168 | pageframes need to live in the permanent mapping, which means: | |
d65bfacb | 169 | |
eeb8a642 MR |
170 | * you can have 896M/sizeof(struct page) page-frames at most; with struct |
171 | page being 32-bytes that would end up being something in the order of 112G | |
172 | worth of pages; the kernel, however, needs to store more than just | |
173 | page-frames in that memory... | |
d65bfacb | 174 | |
eeb8a642 MR |
175 | * PAE makes your page tables larger - which slows the system down as more |
176 | data has to be accessed to traverse in TLB fills and the like. One | |
177 | advantage is that PAE has more PTE bits and can provide advanced features | |
178 | like NX and PAT. | |
d65bfacb PZ |
179 | |
180 | The general recommendation is that you don't use more than 8GiB on a 32-bit | |
181 | machine - although more might work for you and your workload, you're pretty | |
182 | much on your own - don't expect kernel developers to really care much if things | |
183 | come apart. | |
174270c2 FDF |
184 | |
185 | ||
186 | Functions | |
187 | ========= | |
188 | ||
189 | .. kernel-doc:: include/linux/highmem.h | |
190 | .. kernel-doc:: include/linux/highmem-internal.h |