Lines Matching +full:boot +full:- +full:pages
2 .. SPDX-License-Identifier: GPL-2.0
14 default, there is a one-to-one mapping from a page frame to its corresponding
17 HugeTLB pages consist of multiple base page size pages and is supported by many
18 architectures. See Documentation/admin-guide/mm/hugetlbpage.rst for more
19 details. On the x86-64 architecture, HugeTLB pages of size 2MB and 1GB are
21 consists of 512 base pages and a 1GB HugeTLB page consists of 262144 base pages.
27 is the compound_head field, and this field is the same for all tail pages.
29 By removing redundant ``struct page`` for HugeTLB pages, memory can be returned
32 Different architectures support different HugeTLB pages. For example, the
34 architectures. Because arm64 supports 4k, 16k, and 64k base pages and
38 +--------------+-----------+-----------------------------------------------+
40 +--------------+-----------+-----------+-----------+-----------+-----------+
41 | x86-64 | 4KB | 2MB | 1GB | | |
42 +--------------+-----------+-----------+-----------+-----------+-----------+
44 | +-----------+-----------+-----------+-----------+-----------+
46 | +-----------+-----------+-----------+-----------+-----------+
48 +--------------+-----------+-----------+-----------+-----------+-----------+
50 When the system boot up, every HugeTLB page has more than one ``struct page``
51 structs which size is (unit: pages)::
74 = 8 (pages)
79 This optimization only supports 64-bit system, so the value of sizeof(pte_t)
82 x86-64 and arm64). So if we use pmd level mapping for a HugeTLB page, the
89 = PAGE_SIZE / 8 * 8 (pages)
90 = PAGE_SIZE (pages)
99 show the internal implementation of this optimization. There are 8 pages
104 HugeTLB struct pages(8 pages) page frame(8 pages)
105 +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
106 | | | 0 | -------------> | 0 |
107 | | +-----------+ +-----------+
108 | | | 1 | -------------> | 1 |
109 | | +-----------+ +-----------+
110 | | | 2 | -------------> | 2 |
111 | | +-----------+ +-----------+
112 | | | 3 | -------------> | 3 |
113 | | +-----------+ +-----------+
114 | | | 4 | -------------> | 4 |
115 | PMD | +-----------+ +-----------+
116 | level | | 5 | -------------> | 5 |
117 | mapping | +-----------+ +-----------+
118 | | | 6 | -------------> | 6 |
119 | | +-----------+ +-----------+
120 | | | 7 | -------------> | 7 |
121 | | +-----------+ +-----------+
125 +-----------+
127 The value of page->compound_head is the same for all tail pages. The first
130 pages of ``struct page`` (page 1 to page 7) is to point to page->compound_head.
131 Therefore, we can remap pages 1 to 7 to page 0. Only 1 page of ``struct page``
133 7 pages to the buddy allocator.
137 HugeTLB struct pages(8 pages) page frame(8 pages)
138 +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
139 | | | 0 | -------------> | 0 |
140 | | +-----------+ +-----------+
141 | | | 1 | ---------------^ ^ ^ ^ ^ ^ ^
142 | | +-----------+ | | | | | |
143 | | | 2 | -----------------+ | | | | |
144 | | +-----------+ | | | | |
145 | | | 3 | -------------------+ | | | |
146 | | +-----------+ | | | |
147 | | | 4 | ---------------------+ | | |
148 | PMD | +-----------+ | | |
149 | level | | 5 | -----------------------+ | |
150 | mapping | +-----------+ | |
151 | | | 6 | -------------------------+ |
152 | | +-----------+ |
153 | | | 7 | ---------------------------+
154 | | +-----------+
158 +-----------+
160 When a HugeTLB is freed to the buddy system, we should allocate 7 pages for
161 vmemmap pages and restore the previous mapping relationship.
164 We also can use this approach to free (PAGE_SIZE - 1) vmemmap pages.
176 tail vmemmap pages are mapped to the head vmemmap page frame. So we can see
188 The device-dax interface uses the same tail deduplication technique explained
199 to 4 on HugeTLB pages.
201 There's no remapping of vmemmap given that device-dax memory is not part of
202 System RAM ranges initialized at boot. Thus the tail page deduplication
204 the head vmemmap page representing, whereas device-dax reuses the tail
207 Deduplicated tail pages are not mapped read-only.
209 Here's how things look like on device-dax after the sections are populated::
211 +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
212 | | | 0 | -------------> | 0 |
213 | | +-----------+ +-----------+
214 | | | 1 | -------------> | 1 |
215 | | +-----------+ +-----------+
216 | | | 2 | ----------------^ ^ ^ ^ ^ ^
217 | | +-----------+ | | | | |
218 | | | 3 | ------------------+ | | | |
219 | | +-----------+ | | | |
220 | | | 4 | --------------------+ | | |
221 | PMD | +-----------+ | | |
222 | level | | 5 | ----------------------+ | |
223 | mapping | +-----------+ | |
224 | | | 6 | ------------------------+ |
225 | | +-----------+ |
226 | | | 7 | --------------------------+
227 | | +-----------+
231 +-----------+