|
124 | 124 | * page of page structs (page 0) associated with the HugeTLB page contains the 4
|
125 | 125 | * page structs necessary to describe the HugeTLB. The only use of the remaining
|
126 | 126 | * pages of page structs (page 1 to page 7) is to point to page->compound_head.
|
127 |
| - * Therefore, we can remap pages 2 to 7 to page 1. Only 2 pages of page structs |
| 127 | + * Therefore, we can remap pages 1 to 7 to page 0. Only 1 page of page structs |
128 | 128 | * will be used for each HugeTLB page. This will allow us to free the remaining
|
129 |
| - * 6 pages to the buddy allocator. |
| 129 | + * 7 pages to the buddy allocator. |
130 | 130 | *
|
131 | 131 | * Here is how things look after remapping.
|
132 | 132 | *
|
133 | 133 | * HugeTLB struct pages(8 pages) page frame(8 pages)
|
134 | 134 | * +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
|
135 | 135 | * | | | 0 | -------------> | 0 |
|
136 | 136 | * | | +-----------+ +-----------+
|
137 |
| - * | | | 1 | -------------> | 1 | |
138 |
| - * | | +-----------+ +-----------+ |
139 |
| - * | | | 2 | ----------------^ ^ ^ ^ ^ ^ |
140 |
| - * | | +-----------+ | | | | | |
141 |
| - * | | | 3 | ------------------+ | | | | |
142 |
| - * | | +-----------+ | | | | |
143 |
| - * | | | 4 | --------------------+ | | | |
144 |
| - * | PMD | +-----------+ | | | |
145 |
| - * | level | | 5 | ----------------------+ | | |
146 |
| - * | mapping | +-----------+ | | |
147 |
| - * | | | 6 | ------------------------+ | |
148 |
| - * | | +-----------+ | |
149 |
| - * | | | 7 | --------------------------+ |
| 137 | + * | | | 1 | ---------------^ ^ ^ ^ ^ ^ ^ |
| 138 | + * | | +-----------+ | | | | | | |
| 139 | + * | | | 2 | -----------------+ | | | | | |
| 140 | + * | | +-----------+ | | | | | |
| 141 | + * | | | 3 | -------------------+ | | | | |
| 142 | + * | | +-----------+ | | | | |
| 143 | + * | | | 4 | ---------------------+ | | | |
| 144 | + * | PMD | +-----------+ | | | |
| 145 | + * | level | | 5 | -----------------------+ | | |
| 146 | + * | mapping | +-----------+ | | |
| 147 | + * | | | 6 | -------------------------+ | |
| 148 | + * | | +-----------+ | |
| 149 | + * | | | 7 | ---------------------------+ |
150 | 150 | * | | +-----------+
|
151 | 151 | * | |
|
152 | 152 | * | |
|
153 | 153 | * | |
|
154 | 154 | * +-----------+
|
155 | 155 | *
|
156 |
| - * When a HugeTLB is freed to the buddy system, we should allocate 6 pages for |
| 156 | + * When a HugeTLB is freed to the buddy system, we should allocate 7 pages for |
157 | 157 | * vmemmap pages and restore the previous mapping relationship.
|
158 | 158 | *
|
159 | 159 | * For the HugeTLB page of the pud level mapping. It is similar to the former.
|
160 |
| - * We also can use this approach to free (PAGE_SIZE - 2) vmemmap pages. |
| 160 | + * We also can use this approach to free (PAGE_SIZE - 1) vmemmap pages. |
161 | 161 | *
|
162 | 162 | * Apart from the HugeTLB page of the pmd/pud level mapping, some architectures
|
163 | 163 | * (e.g. aarch64) provides a contiguous bit in the translation table entries
|
|
166 | 166 | *
|
167 | 167 | * The contiguous bit is used to increase the mapping size at the pmd and pte
|
168 | 168 | * (last) level. So this type of HugeTLB page can be optimized only when its
|
169 |
| - * size of the struct page structs is greater than 2 pages. |
| 169 | + * size of the struct page structs is greater than 1 page. |
| 170 | + * |
| 171 | + * Notice: The head vmemmap page is not freed to the buddy allocator and all |
| 172 | + * tail vmemmap pages are mapped to the head vmemmap page frame. So we can see |
| 173 | + * more than one struct page struct with PG_head (e.g. 8 per 2 MB HugeTLB page) |
| 174 | + * associated with each HugeTLB page. The compound_head() can handle this |
| 175 | + * correctly (more details refer to the comment above compound_head()). |
170 | 176 | */
|
171 | 177 | #define pr_fmt(fmt) "HugeTLB: " fmt
|
172 | 178 |
|
|
175 | 181 | /*
|
176 | 182 | * There are a lot of struct page structures associated with each HugeTLB page.
|
177 | 183 | * For tail pages, the value of compound_head is the same. So we can reuse first
|
178 |
| - * page of tail page structures. We map the virtual addresses of the remaining |
179 |
| - * pages of tail page structures to the first tail page struct, and then free |
180 |
| - * these page frames. Therefore, we need to reserve two pages as vmemmap areas. |
| 184 | + * page of head page structures. We map the virtual addresses of all the pages |
| 185 | + * of tail page structures to the head page struct, and then free these page |
| 186 | + * frames. Therefore, we need to reserve one pages as vmemmap areas. |
181 | 187 | */
|
182 |
| -#define RESERVE_VMEMMAP_NR 2U |
| 188 | +#define RESERVE_VMEMMAP_NR 1U |
183 | 189 | #define RESERVE_VMEMMAP_SIZE (RESERVE_VMEMMAP_NR << PAGE_SHIFT)
|
184 | 190 |
|
185 |
| -bool hugetlb_free_vmemmap_enabled = IS_ENABLED(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON); |
| 191 | +bool hugetlb_free_vmemmap_enabled __read_mostly = |
| 192 | + IS_ENABLED(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON); |
| 193 | +EXPORT_SYMBOL(hugetlb_free_vmemmap_enabled); |
186 | 194 |
|
187 | 195 | static int __init early_hugetlb_free_vmemmap_param(char *buf)
|
188 | 196 | {
|
189 | 197 | /* We cannot optimize if a "struct page" crosses page boundaries. */
|
190 |
| - if ((!is_power_of_2(sizeof(struct page)))) { |
| 198 | + if (!is_power_of_2(sizeof(struct page))) { |
191 | 199 | pr_warn("cannot free vmemmap pages because \"struct page\" crosses page boundaries\n");
|
192 | 200 | return 0;
|
193 | 201 | }
|
@@ -236,7 +244,6 @@ int alloc_huge_page_vmemmap(struct hstate *h, struct page *head)
|
236 | 244 | */
|
237 | 245 | ret = vmemmap_remap_alloc(vmemmap_addr, vmemmap_end, vmemmap_reuse,
|
238 | 246 | GFP_KERNEL | __GFP_NORETRY | __GFP_THISNODE);
|
239 |
| - |
240 | 247 | if (!ret)
|
241 | 248 | ClearHPageVmemmapOptimized(head);
|
242 | 249 |
|
@@ -282,9 +289,8 @@ void __init hugetlb_vmemmap_init(struct hstate *h)
|
282 | 289 |
|
283 | 290 | vmemmap_pages = (nr_pages * sizeof(struct page)) >> PAGE_SHIFT;
|
284 | 291 | /*
|
285 |
| - * The head page and the first tail page are not to be freed to buddy |
286 |
| - * allocator, the other pages will map to the first tail page, so they |
287 |
| - * can be freed. |
| 292 | + * The head page is not to be freed to buddy allocator, the other tail |
| 293 | + * pages will map to the head page, so they can be freed. |
288 | 294 | *
|
289 | 295 | * Could RESERVE_VMEMMAP_NR be greater than @vmemmap_pages? It is true
|
290 | 296 | * on some architectures (e.g. aarch64). See Documentation/arm64/
|
|
0 commit comments