Muchun Song | f41f2ed | 2021-06-30 18:47:13 -0700 | [diff] [blame^] | 1 | // SPDX-License-Identifier: GPL-2.0 |
| 2 | /* |
| 3 | * Free some vmemmap pages of HugeTLB |
| 4 | * |
| 5 | * Copyright (c) 2020, Bytedance. All rights reserved. |
| 6 | * |
| 7 | * Author: Muchun Song <songmuchun@bytedance.com> |
| 8 | * |
| 9 | * The struct page structures (page structs) are used to describe a physical |
| 10 | * page frame. By default, there is a one-to-one mapping from a page frame to |
| 11 | * it's corresponding page struct. |
| 12 | * |
| 13 | * HugeTLB pages consist of multiple base page size pages and is supported by |
| 14 | * many architectures. See hugetlbpage.rst in the Documentation directory for |
| 15 | * more details. On the x86-64 architecture, HugeTLB pages of size 2MB and 1GB |
| 16 | * are currently supported. Since the base page size on x86 is 4KB, a 2MB |
| 17 | * HugeTLB page consists of 512 base pages and a 1GB HugeTLB page consists of |
| 18 | * 4096 base pages. For each base page, there is a corresponding page struct. |
| 19 | * |
| 20 | * Within the HugeTLB subsystem, only the first 4 page structs are used to |
| 21 | * contain unique information about a HugeTLB page. __NR_USED_SUBPAGE provides |
| 22 | * this upper limit. The only 'useful' information in the remaining page structs |
| 23 | * is the compound_head field, and this field is the same for all tail pages. |
| 24 | * |
| 25 | * By removing redundant page structs for HugeTLB pages, memory can be returned |
| 26 | * to the buddy allocator for other uses. |
| 27 | * |
| 28 | * Different architectures support different HugeTLB pages. For example, the |
| 29 | * following table is the HugeTLB page size supported by x86 and arm64 |
| 30 | * architectures. Because arm64 supports 4k, 16k, and 64k base pages and |
| 31 | * supports contiguous entries, so it supports many kinds of sizes of HugeTLB |
| 32 | * page. |
| 33 | * |
| 34 | * +--------------+-----------+-----------------------------------------------+ |
| 35 | * | Architecture | Page Size | HugeTLB Page Size | |
| 36 | * +--------------+-----------+-----------+-----------+-----------+-----------+ |
| 37 | * | x86-64 | 4KB | 2MB | 1GB | | | |
| 38 | * +--------------+-----------+-----------+-----------+-----------+-----------+ |
| 39 | * | | 4KB | 64KB | 2MB | 32MB | 1GB | |
| 40 | * | +-----------+-----------+-----------+-----------+-----------+ |
| 41 | * | arm64 | 16KB | 2MB | 32MB | 1GB | | |
| 42 | * | +-----------+-----------+-----------+-----------+-----------+ |
| 43 | * | | 64KB | 2MB | 512MB | 16GB | | |
| 44 | * +--------------+-----------+-----------+-----------+-----------+-----------+ |
| 45 | * |
| 46 | * When the system boot up, every HugeTLB page has more than one struct page |
| 47 | * structs which size is (unit: pages): |
| 48 | * |
| 49 | * struct_size = HugeTLB_Size / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE |
| 50 | * |
| 51 | * Where HugeTLB_Size is the size of the HugeTLB page. We know that the size |
| 52 | * of the HugeTLB page is always n times PAGE_SIZE. So we can get the following |
| 53 | * relationship. |
| 54 | * |
| 55 | * HugeTLB_Size = n * PAGE_SIZE |
| 56 | * |
| 57 | * Then, |
| 58 | * |
| 59 | * struct_size = n * PAGE_SIZE / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE |
| 60 | * = n * sizeof(struct page) / PAGE_SIZE |
| 61 | * |
| 62 | * We can use huge mapping at the pud/pmd level for the HugeTLB page. |
| 63 | * |
| 64 | * For the HugeTLB page of the pmd level mapping, then |
| 65 | * |
| 66 | * struct_size = n * sizeof(struct page) / PAGE_SIZE |
| 67 | * = PAGE_SIZE / sizeof(pte_t) * sizeof(struct page) / PAGE_SIZE |
| 68 | * = sizeof(struct page) / sizeof(pte_t) |
| 69 | * = 64 / 8 |
| 70 | * = 8 (pages) |
| 71 | * |
| 72 | * Where n is how many pte entries which one page can contains. So the value of |
| 73 | * n is (PAGE_SIZE / sizeof(pte_t)). |
| 74 | * |
| 75 | * This optimization only supports 64-bit system, so the value of sizeof(pte_t) |
| 76 | * is 8. And this optimization also applicable only when the size of struct page |
| 77 | * is a power of two. In most cases, the size of struct page is 64 bytes (e.g. |
| 78 | * x86-64 and arm64). So if we use pmd level mapping for a HugeTLB page, the |
| 79 | * size of struct page structs of it is 8 page frames which size depends on the |
| 80 | * size of the base page. |
| 81 | * |
| 82 | * For the HugeTLB page of the pud level mapping, then |
| 83 | * |
| 84 | * struct_size = PAGE_SIZE / sizeof(pmd_t) * struct_size(pmd) |
| 85 | * = PAGE_SIZE / 8 * 8 (pages) |
| 86 | * = PAGE_SIZE (pages) |
| 87 | * |
| 88 | * Where the struct_size(pmd) is the size of the struct page structs of a |
| 89 | * HugeTLB page of the pmd level mapping. |
| 90 | * |
| 91 | * E.g.: A 2MB HugeTLB page on x86_64 consists in 8 page frames while 1GB |
| 92 | * HugeTLB page consists in 4096. |
| 93 | * |
| 94 | * Next, we take the pmd level mapping of the HugeTLB page as an example to |
| 95 | * show the internal implementation of this optimization. There are 8 pages |
| 96 | * struct page structs associated with a HugeTLB page which is pmd mapped. |
| 97 | * |
| 98 | * Here is how things look before optimization. |
| 99 | * |
| 100 | * HugeTLB struct pages(8 pages) page frame(8 pages) |
| 101 | * +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ |
| 102 | * | | | 0 | -------------> | 0 | |
| 103 | * | | +-----------+ +-----------+ |
| 104 | * | | | 1 | -------------> | 1 | |
| 105 | * | | +-----------+ +-----------+ |
| 106 | * | | | 2 | -------------> | 2 | |
| 107 | * | | +-----------+ +-----------+ |
| 108 | * | | | 3 | -------------> | 3 | |
| 109 | * | | +-----------+ +-----------+ |
| 110 | * | | | 4 | -------------> | 4 | |
| 111 | * | PMD | +-----------+ +-----------+ |
| 112 | * | level | | 5 | -------------> | 5 | |
| 113 | * | mapping | +-----------+ +-----------+ |
| 114 | * | | | 6 | -------------> | 6 | |
| 115 | * | | +-----------+ +-----------+ |
| 116 | * | | | 7 | -------------> | 7 | |
| 117 | * | | +-----------+ +-----------+ |
| 118 | * | | |
| 119 | * | | |
| 120 | * | | |
| 121 | * +-----------+ |
| 122 | * |
| 123 | * The value of page->compound_head is the same for all tail pages. The first |
| 124 | * page of page structs (page 0) associated with the HugeTLB page contains the 4 |
| 125 | * page structs necessary to describe the HugeTLB. The only use of the remaining |
| 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 |
| 128 | * will be used for each HugeTLB page. This will allow us to free the remaining |
| 129 | * 6 pages to the buddy allocator. |
| 130 | * |
| 131 | * Here is how things look after remapping. |
| 132 | * |
| 133 | * HugeTLB struct pages(8 pages) page frame(8 pages) |
| 134 | * +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ |
| 135 | * | | | 0 | -------------> | 0 | |
| 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 | --------------------------+ |
| 150 | * | | +-----------+ |
| 151 | * | | |
| 152 | * | | |
| 153 | * | | |
| 154 | * +-----------+ |
| 155 | * |
| 156 | * When a HugeTLB is freed to the buddy system, we should allocate 6 pages for |
| 157 | * vmemmap pages and restore the previous mapping relationship. |
| 158 | * |
| 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. |
| 161 | * |
| 162 | * Apart from the HugeTLB page of the pmd/pud level mapping, some architectures |
| 163 | * (e.g. aarch64) provides a contiguous bit in the translation table entries |
| 164 | * that hints to the MMU to indicate that it is one of a contiguous set of |
| 165 | * entries that can be cached in a single TLB entry. |
| 166 | * |
| 167 | * The contiguous bit is used to increase the mapping size at the pmd and pte |
| 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. |
| 170 | */ |
| 171 | #include "hugetlb_vmemmap.h" |
| 172 | |
| 173 | /* |
| 174 | * There are a lot of struct page structures associated with each HugeTLB page. |
| 175 | * For tail pages, the value of compound_head is the same. So we can reuse first |
| 176 | * page of tail page structures. We map the virtual addresses of the remaining |
| 177 | * pages of tail page structures to the first tail page struct, and then free |
| 178 | * these page frames. Therefore, we need to reserve two pages as vmemmap areas. |
| 179 | */ |
| 180 | #define RESERVE_VMEMMAP_NR 2U |
| 181 | #define RESERVE_VMEMMAP_SIZE (RESERVE_VMEMMAP_NR << PAGE_SHIFT) |
| 182 | |
| 183 | /* |
| 184 | * How many vmemmap pages associated with a HugeTLB page that can be freed |
| 185 | * to the buddy allocator. |
| 186 | * |
| 187 | * Todo: Returns zero for now, which means the feature is disabled. We will |
| 188 | * enable it once all the infrastructure is there. |
| 189 | */ |
| 190 | static inline unsigned int free_vmemmap_pages_per_hpage(struct hstate *h) |
| 191 | { |
| 192 | return 0; |
| 193 | } |
| 194 | |
| 195 | static inline unsigned long free_vmemmap_pages_size_per_hpage(struct hstate *h) |
| 196 | { |
| 197 | return (unsigned long)free_vmemmap_pages_per_hpage(h) << PAGE_SHIFT; |
| 198 | } |
| 199 | |
| 200 | void free_huge_page_vmemmap(struct hstate *h, struct page *head) |
| 201 | { |
| 202 | unsigned long vmemmap_addr = (unsigned long)head; |
| 203 | unsigned long vmemmap_end, vmemmap_reuse; |
| 204 | |
| 205 | if (!free_vmemmap_pages_per_hpage(h)) |
| 206 | return; |
| 207 | |
| 208 | vmemmap_addr += RESERVE_VMEMMAP_SIZE; |
| 209 | vmemmap_end = vmemmap_addr + free_vmemmap_pages_size_per_hpage(h); |
| 210 | vmemmap_reuse = vmemmap_addr - PAGE_SIZE; |
| 211 | |
| 212 | /* |
| 213 | * Remap the vmemmap virtual address range [@vmemmap_addr, @vmemmap_end) |
| 214 | * to the page which @vmemmap_reuse is mapped to, then free the pages |
| 215 | * which the range [@vmemmap_addr, @vmemmap_end] is mapped to. |
| 216 | */ |
| 217 | vmemmap_remap_free(vmemmap_addr, vmemmap_end, vmemmap_reuse); |
| 218 | } |