tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

hugetlb: update vmemmap_dedup.rst

Update the documentation regarding vmemmap optimization for hugetlb to
reflect the changes in how the kernel maps the tail pages.

Fake heads no longer exist. Remove their description.

[kas@kernel.org: update vmemmap_dedup.rst]
Link: https://lkml.kernel.org/r/20260302105630.303492-1-kas@kernel.org
Link: https://lkml.kernel.org/r/20260227194302.274384-18-kas@kernel.org
Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
Reviewed-by: Muchun Song <muchun.song@linux.dev>
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Baoquan He <bhe@redhat.com>
Cc: Christoph Lameter <cl@gentwo.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Harry Yoo <harry.yoo@oracle.com>
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Usama Arif <usamaarif642@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

authored by

Kiryl Shutsemau and committed by
Andrew Morton fed8676c 66b2a3d9

+26 -34
+26 -34
Documentation/mm/vmemmap_dedup.rst
··· 124 124 | | 125 125 +-----------+ 126 126 127 - The value of page->compound_info is the same for all tail pages. The first 128 - page of ``struct page`` (page 0) associated with the HugeTLB page contains the 4 129 - ``struct page`` necessary to describe the HugeTLB. The only use of the remaining 130 - pages of ``struct page`` (page 1 to page 7) is to point to page->compound_info. 131 - Therefore, we can remap pages 1 to 7 to page 0. Only 1 page of ``struct page`` 132 - will be used for each HugeTLB page. This will allow us to free the remaining 133 - 7 pages to the buddy allocator. 127 + The first page of ``struct page`` (page 0) associated with the HugeTLB page 128 + contains the 4 ``struct page`` necessary to describe the HugeTLB. The remaining 129 + pages of ``struct page`` (page 1 to page 7) are tail pages. 130 + 131 + The optimization is only applied when the size of the struct page is a power 132 + of 2. In this case, all tail pages of the same order are identical. See 133 + compound_head(). This allows us to remap the tail pages of the vmemmap to a 134 + shared, read-only page. The head page is also remapped to a new page. This 135 + allows the original vmemmap pages to be freed. 134 136 135 137 Here is how things look after remapping:: 136 138 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 | ---------------------------+ 139 + HugeTLB struct pages(8 pages) page frame (new) 140 + +-----------+ ---virt_to_page---> +-----------+ mapping to +----------------+ 141 + | | | 0 | -------------> | 0 | 142 + | | +-----------+ +----------------+ 143 + | | | 1 | ------┐ 144 + | | +-----------+ | 145 + | | | 2 | ------┼ +----------------------------+ 146 + | | +-----------+ | | A single, per-zone page | 147 + | | | 3 | ------┼------> | frame shared among all | 148 + | | +-----------+ | | hugepages of the same size | 149 + | | | 4 | ------┼ +----------------------------+ 150 + | | +-----------+ | 151 + | | | 5 | ------┼ 152 + | PMD | +-----------+ | 153 + | level | | 6 | ------┼ 154 + | mapping | +-----------+ | 155 + | | | 7 | ------┘ 154 156 | | +-----------+ 155 157 | | 156 158 | | ··· 173 171 The contiguous bit is used to increase the mapping size at the pmd and pte 174 172 (last) level. So this type of HugeTLB page can be optimized only when its 175 173 size of the ``struct page`` structs is greater than **1** page. 176 - 177 - Notice: The head vmemmap page is not freed to the buddy allocator and all 178 - tail vmemmap pages are mapped to the head vmemmap page frame. So we can see 179 - more than one ``struct page`` struct with ``PG_head`` (e.g. 8 per 2 MB HugeTLB 180 - page) associated with each HugeTLB page. The ``compound_head()`` can handle 181 - this correctly. There is only **one** head ``struct page``, the tail 182 - ``struct page`` with ``PG_head`` are fake head ``struct page``. We need an 183 - approach to distinguish between those two different types of ``struct page`` so 184 - that ``compound_head()`` can return the real head ``struct page`` when the 185 - parameter is the tail ``struct page`` but with ``PG_head``. 186 174 187 175 Device DAX 188 176 ==========