요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
2
.. SPDX-License-Identifier: GPL-2.0
4
=========================================
5
A vmemmap diet for HugeTLB and Device DAX
6
=========================================
8
HugeTLB
9
=======
11
This section is to explain how HugeTLB Vmemmap Optimization (HVO) works.
13
The ``struct page`` structures are used to describe a physical page frame. By
14
default, there is a one-to-one mapping from a page frame to its corresponding
15
``struct page``.
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
20
currently supported. Since the base page size on x86 is 4KB, a 2MB HugeTLB page
21
consists of 512 base pages and a 1GB HugeTLB page consists of 262144 base pages.
22
For each base page, there is a corresponding ``struct page``.
24
Within the HugeTLB subsystem, only the first 4 ``struct page`` are used to
25
contain unique information about a HugeTLB page. ``__NR_USED_SUBPAGE`` provides
26
this upper limit. The only 'useful' information in the remaining ``struct page``
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
30
to the buddy allocator for other uses.
32
Different architectures support different HugeTLB pages. For example, the
33
following table is the HugeTLB page size supported by x86 and arm64
34
architectures. Because arm64 supports 4k, 16k, and 64k base pages and
35
supports contiguous entries, so it supports many kinds of sizes of HugeTLB
36
page.
38
+--------------+-----------+-----------------------------------------------+
39
| Architecture | Page Size | HugeTLB Page Size |
40
+--------------+-----------+-----------+-----------+-----------+-----------+
41
| x86-64 | 4KB | 2MB | 1GB | | |
42
+--------------+-----------+-----------+-----------+-----------+-----------+
43
| | 4KB | 64KB | 2MB | 32MB | 1GB |
44
| +-----------+-----------+-----------+-----------+-----------+
45
| arm64 | 16KB | 2MB | 32MB | 1GB | |
46
| +-----------+-----------+-----------+-----------+-----------+
47
| | 64KB | 2MB | 512MB | 16GB | |
48
+--------------+-----------+-----------+-----------+-----------+-----------+
50
When the system boot up, every HugeTLB page has more than one ``struct page``
51
structs which size is (unit: pages)::
53
struct_size = HugeTLB_Size / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE
55
Where HugeTLB_Size is the size of the HugeTLB page. We know that the size
56
of the HugeTLB page is always n times PAGE_SIZE. So we can get the following
57
relationship::
59
HugeTLB_Size = n * PAGE_SIZE
61
Then::
63
struct_size = n * PAGE_SIZE / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE
64
= n * sizeof(struct page) / PAGE_SIZE
66
We can use huge mapping at the pud/pmd level for the HugeTLB page.
68
For the HugeTLB page of the pmd level mapping, then::
70
struct_size = n * sizeof(struct page) / PAGE_SIZE
71
= PAGE_SIZE / sizeof(pte_t) * sizeof(struct page) / PAGE_SIZE
72
= sizeof(struct page) / sizeof(pte_t)
73
= 64 / 8
74
= 8 (pages)
76
Where n is how many pte entries which one page can contains. So the value of
77
n is (PAGE_SIZE / sizeof(pte_t)).
79
This optimization only supports 64-bit system, so the value of sizeof(pte_t)
80
is 8. And this optimization also applicable only when the size of ``struct page``
81
is a power of two. In most cases, the size of ``struct page`` is 64 bytes (e.g.
82
x86-64 and arm64). So if we use pmd level mapping for a HugeTLB page, the
83
size of ``struct page`` structs of it is 8 page frames which size depends on the
84
size of the base page.
86
For the HugeTLB page of the pud level mapping, then::
88
struct_size = PAGE_SIZE / sizeof(pmd_t) * struct_size(pmd)
89
= PAGE_SIZE / 8 * 8 (pages)
90
= PAGE_SIZE (pages)
92
Where the struct_size(pmd) is the size of the ``struct page`` structs of a
93
HugeTLB page of the pmd level mapping.
95
E.g.: A 2MB HugeTLB page on x86_64 consists in 8 page frames while 1GB
96
HugeTLB page consists in 4096.
98
Next, we take the pmd level mapping of the HugeTLB page as an example to
99
show the internal implementation of this optimization. There are 8 pages
100
``struct page`` structs associated with a HugeTLB page which is pmd mapped.
102
Here is how things look before optimization::
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
| | +-----------+ +-----------+
122
| |
123
| |
124
| |
125
+-----------+
127
The value of page->compound_head 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_head.
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.
135
Here is how things look after remapping::
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
| | +-----------+
155
| |
156
| |
157
| |
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.
163
For the HugeTLB page of the pud level mapping. It is similar to the former.
164
We also can use this approach to free (PAGE_SIZE - 1) vmemmap pages.
166
Apart from the HugeTLB page of the pmd/pud level mapping, some architectures
167
(e.g. aarch64) provides a contiguous bit in the translation table entries
168
that hints to the MMU to indicate that it is one of a contiguous set of
169
entries that can be cached in a single TLB entry.
171
The contiguous bit is used to increase the mapping size at the pmd and pte
172
(last) level. So this type of HugeTLB page can be optimized only when its
173
size of the ``struct page`` structs is greater than **1** page.
175
Notice: The head vmemmap page is not freed to the buddy allocator and all
176
tail vmemmap pages are mapped to the head vmemmap page frame. So we can see
177
more than one ``struct page`` struct with ``PG_head`` (e.g. 8 per 2 MB HugeTLB
178
page) associated with each HugeTLB page. The ``compound_head()`` can handle
179
this correctly. There is only **one** head ``struct page``, the tail
180
``struct page`` with ``PG_head`` are fake head ``struct page``. We need an
181
approach to distinguish between those two different types of ``struct page`` so
182
that ``compound_head()`` can return the real head ``struct page`` when the
183
parameter is the tail ``struct page`` but with ``PG_head``.
185
Device DAX
186
==========
188
The device-dax interface uses the same tail deduplication technique explained
189
in the previous chapter, except when used with the vmemmap in
190
the device (altmap).
192
The following page sizes are supported in DAX: PAGE_SIZE (4K on x86_64),
193
PMD_SIZE (2M on x86_64) and PUD_SIZE (1G on x86_64).
194
For powerpc equivalent details see Documentation/arch/powerpc/vmemmap_dedup.rst
196
The differences with HugeTLB are relatively minor.
198
It only use 3 ``struct page`` for storing all information as opposed
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
203
happens at a later stage when we populate the sections. HugeTLB reuses the
204
the head vmemmap page representing, whereas device-dax reuses the tail
205
vmemmap page. This results in only half of the savings compared to HugeTLB.
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
| | +-----------+
228
| |
229
| |
230
| |
231
+-----------+
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
HugeTLB Vmemmap Optimization의 목적
1-30HugeTLB와 Device DAX를 위한 vmemmap 절약
HugeTLB
이 절은 HugeTLB Vmemmap Optimization(HVO)이 동작하는 방식을 설명합니다.
`struct page`는 physical page frame을 설명하며 기본적으로 page frame 하나와 해당 `struct page` 하나가 일대일로 mapping됩니다.
HugeTLB page는 여러 base-page-size page로 이루어지며 많은 architecture가 지원합니다. 자세한 내용은 `Documentation/admin-guide/mm/hugetlbpage.rst`를 참고하십시오. X86-64는 현재 2MB와 1GB HugeTLB page를 지원합니다. Base page가 4KB이므로 각각 512개와 262,144개의 base page로 구성되며, 기본 구조에서는 base page마다 `struct page`가 하나씩 있습니다.
HugeTLB subsystem은 HugeTLB page의 고유 정보를 저장하는 데 첫 4개의 `struct page`만 사용합니다. 이 상한은 `__NR_USED_SUBPAGE`가 나타냅니다. 나머지 `struct page`에서 유용한 정보는 모든 tail page에서 동일한 `compound_head`뿐입니다.
이 중복 `struct page`를 제거하면 해당 memory를 buddy allocator에 돌려 다른 용도로 사용할 수 있습니다.
.. SPDX-License-Identifier: GPL-2.0
=========================================
A vmemmap diet for HugeTLB and Device DAX
=========================================
HugeTLB
=======
This section is to explain how HugeTLB Vmemmap Optimization (HVO) works.
The ``struct page`` structures are used to describe a physical page frame. By
default, there is a one-to-one mapping from a page frame to its corresponding
``struct page``.
HugeTLB pages consist of multiple base page size pages and is supported by many
architectures. See Documentation/admin-guide/mm/hugetlbpage.rst for more
details. On the x86-64 architecture, HugeTLB pages of size 2MB and 1GB are
currently supported. Since the base page size on x86 is 4KB, a 2MB HugeTLB page
consists of 512 base pages and a 1GB HugeTLB page consists of 262144 base pages.
For each base page, there is a corresponding ``struct page``.
Within the HugeTLB subsystem, only the first 4 ``struct page`` are used to
contain unique information about a HugeTLB page. ``__NR_USED_SUBPAGE`` provides
this upper limit. The only 'useful' information in the remaining ``struct page``
is the compound_head field, and this field is the same for all tail pages.
By removing redundant ``struct page`` for HugeTLB pages, memory can be returned
to the buddy allocator for other uses.Architecture별 page size
31-49Architecture마다 지원하는 HugeTLB page size가 다릅니다. Arm64는 4KB·16KB·64KB base page와 contiguous entry를 지원하므로 다양한 HugeTLB size를 제공합니다.
원문 표에서 x86-64의 4KB base page는 2MB와 1GB HugeTLB를 지원합니다. Arm64는 4KB base page에서 64KB·2MB·32MB·1GB, 16KB에서 2MB·32MB·1GB, 64KB에서 2MB·512MB·16GB를 지원합니다.
Different architectures support different HugeTLB pages. For example, the
following table is the HugeTLB page size supported by x86 and arm64
architectures. Because arm64 supports 4k, 16k, and 64k base pages and
supports contiguous entries, so it supports many kinds of sizes of HugeTLB
page.
+--------------+-----------+-----------------------------------------------+
| Architecture | Page Size | HugeTLB Page Size |
+--------------+-----------+-----------+-----------+-----------+-----------+
| x86-64 | 4KB | 2MB | 1GB | | |
+--------------+-----------+-----------+-----------+-----------+-----------+
| | 4KB | 64KB | 2MB | 32MB | 1GB |
| +-----------+-----------+-----------+-----------+-----------+
| arm64 | 16KB | 2MB | 32MB | 1GB | |
| +-----------+-----------+-----------+-----------+-----------+
| | 64KB | 2MB | 512MB | 16GB | |
+--------------+-----------+-----------+-----------+-----------+-----------+
Vmemmap 구조 page 수 계산
50-97Boot 시 HugeTLB page마다 여러 page 크기의 `struct page` 배열이 필요합니다. Page 단위 크기는 다음 식입니다.
struct_size = HugeTLB_Size / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE`HugeTLB_Size = n * PAGE_SIZE`이므로 식은 `struct_size = n * sizeof(struct page) / PAGE_SIZE`로 줄어듭니다.
HugeTLB page는 PUD 또는 PMD 단계의 huge mapping을 사용할 수 있습니다. PMD 단계 mapping에서 한 page에 들어가는 PTE 수는 `n = PAGE_SIZE / sizeof(pte_t)`이므로 `struct_size = sizeof(struct page) / sizeof(pte_t)`입니다.
이 최적화는 64비트 시스템만 지원해 `sizeof(pte_t)`가 8이고, `sizeof(struct page)`가 2의 거듭제곱일 때만 적용됩니다. 흔한 64-byte `struct page`에서는 PMD-mapped HugeTLB 하나의 vmemmap이 base-page size에 따라 8 page frame을 차지합니다.
PUD 단계에서는 `struct_size = PAGE_SIZE / sizeof(pmd_t) * struct_size(pmd) = PAGE_SIZE / 8 * 8 pages = PAGE_SIZE pages`가 됩니다.
예를 들어 x86_64의 2MB HugeTLB page는 `struct page` 저장에 8 page frame, 1GB HugeTLB page는 4,096 page frame을 사용합니다.
When the system boot up, every HugeTLB page has more than one ``struct page``
structs which size is (unit: pages)::
struct_size = HugeTLB_Size / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE
Where HugeTLB_Size is the size of the HugeTLB page. We know that the size
of the HugeTLB page is always n times PAGE_SIZE. So we can get the following
relationship::
HugeTLB_Size = n * PAGE_SIZE
Then::
struct_size = n * PAGE_SIZE / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE
= n * sizeof(struct page) / PAGE_SIZE
We can use huge mapping at the pud/pmd level for the HugeTLB page.
For the HugeTLB page of the pmd level mapping, then::
struct_size = n * sizeof(struct page) / PAGE_SIZE
= PAGE_SIZE / sizeof(pte_t) * sizeof(struct page) / PAGE_SIZE
= sizeof(struct page) / sizeof(pte_t)
= 64 / 8
= 8 (pages)
Where n is how many pte entries which one page can contains. So the value of
n is (PAGE_SIZE / sizeof(pte_t)).
This optimization only supports 64-bit system, so the value of sizeof(pte_t)
is 8. And this optimization also applicable only when the size of ``struct page``
is a power of two. In most cases, the size of ``struct page`` is 64 bytes (e.g.
x86-64 and arm64). So if we use pmd level mapping for a HugeTLB page, the
size of ``struct page`` structs of it is 8 page frames which size depends on the
size of the base page.
For the HugeTLB page of the pud level mapping, then::
struct_size = PAGE_SIZE / sizeof(pmd_t) * struct_size(pmd)
= PAGE_SIZE / 8 * 8 (pages)
= PAGE_SIZE (pages)
Where the struct_size(pmd) is the size of the ``struct page`` structs of a
HugeTLB page of the pmd level mapping.
E.g.: A 2MB HugeTLB page on x86_64 consists in 8 page frames while 1GB
HugeTLB page consists in 4096.
PMD mapping 최적화 전 구조
98-134PMD 단계 HugeTLB page를 예로 들면 관련 `struct page` 배열은 8 page를 차지합니다. 최적화 전에는 vmemmap page 0부터 7까지가 각각 별도의 page frame 0부터 7에 mapping됩니다.
첫 vmemmap page인 page 0에는 HugeTLB를 설명하는 데 필요한 4개의 `struct page`가 들어갑니다. Page 1부터 7의 유일한 용도는 같은 `page->compound_head`를 가리키는 것입니다.
따라서 vmemmap page 1~7의 virtual mapping을 page 0의 physical frame으로 remap할 수 있습니다. HugeTLB page마다 실제 `struct page` backing page 하나만 남기고 나머지 7 page를 buddy allocator에 반환합니다.
Next, we take the pmd level mapping of the HugeTLB page as an example to
show the internal implementation of this optimization. There are 8 pages
``struct page`` structs associated with a HugeTLB page which is pmd mapped.
Here is how things look before optimization::
HugeTLB struct pages(8 pages) page frame(8 pages)
+-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
| | | 0 | -------------> | 0 |
| | +-----------+ +-----------+
| | | 1 | -------------> | 1 |
| | +-----------+ +-----------+
| | | 2 | -------------> | 2 |
| | +-----------+ +-----------+
| | | 3 | -------------> | 3 |
| | +-----------+ +-----------+
| | | 4 | -------------> | 4 |
| PMD | +-----------+ +-----------+
| level | | 5 | -------------> | 5 |
| mapping | +-----------+ +-----------+
| | | 6 | -------------> | 6 |
| | +-----------+ +-----------+
| | | 7 | -------------> | 7 |
| | +-----------+ +-----------+
| |
| |
| |
+-----------+
The value of page->compound_head is the same for all tail pages. The first
page of ``struct page`` (page 0) associated with the HugeTLB page contains the 4
``struct page`` necessary to describe the HugeTLB. The only use of the remaining
pages of ``struct page`` (page 1 to page 7) is to point to page->compound_head.
Therefore, we can remap pages 1 to 7 to page 0. Only 1 page of ``struct page``
will be used for each HugeTLB page. This will allow us to free the remaining
7 pages to the buddy allocator.
Remap 이후 복원과 fake head
135-184Remap 뒤에는 vmemmap virtual page 0~7이 모두 같은 head vmemmap page frame 0을 가리킵니다. Virtual address와 `struct page` slot은 유지되지만 physical backing은 공유됩니다.
HugeTLB page를 buddy system에 free할 때는 vmemmap용 page 7개를 다시 할당하고 원래의 일대일 mapping 관계를 복원해야 합니다.
PUD 단계도 같은 원리로 `PAGE_SIZE - 1`개의 vmemmap page를 free할 수 있습니다.
Aarch64 같은 일부 architecture는 translation-table entry의 contiguous bit로 연속 entry 묶음을 MMU가 TLB entry 하나에 cache할 수 있다고 알립니다. 이 bit는 PMD와 마지막 PTE 단계의 mapping size를 키웁니다. 이런 HugeTLB는 해당 `struct page` 배열이 한 page보다 클 때만 최적화할 수 있습니다.
Head vmemmap page는 buddy allocator로 반환하지 않고 모든 tail vmemmap virtual page를 head frame에 mapping합니다. 따라서 HugeTLB 하나에 `PG_head`가 설정된 `struct page`가 여러 개 보일 수 있습니다. 예를 들어 2MB HugeTLB마다 8개입니다.
실제 head `struct page`는 하나뿐이며, tail 위치에서 보이는 나머지는 fake head입니다. `compound_head()`는 이 차이를 처리해 `PG_head`가 보이는 tail `struct page`를 받더라도 real head를 반환해야 합니다.
Here is how things look after remapping::
HugeTLB struct pages(8 pages) page frame(8 pages)
+-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
| | | 0 | -------------> | 0 |
| | +-----------+ +-----------+
| | | 1 | ---------------^ ^ ^ ^ ^ ^ ^
| | +-----------+ | | | | | |
| | | 2 | -----------------+ | | | | |
| | +-----------+ | | | | |
| | | 3 | -------------------+ | | | |
| | +-----------+ | | | |
| | | 4 | ---------------------+ | | |
| PMD | +-----------+ | | |
| level | | 5 | -----------------------+ | |
| mapping | +-----------+ | |
| | | 6 | -------------------------+ |
| | +-----------+ |
| | | 7 | ---------------------------+
| | +-----------+
| |
| |
| |
+-----------+
When a HugeTLB is freed to the buddy system, we should allocate 7 pages for
vmemmap pages and restore the previous mapping relationship.
For the HugeTLB page of the pud level mapping. It is similar to the former.
We also can use this approach to free (PAGE_SIZE - 1) vmemmap pages.
Apart from the HugeTLB page of the pmd/pud level mapping, some architectures
(e.g. aarch64) provides a contiguous bit in the translation table entries
that hints to the MMU to indicate that it is one of a contiguous set of
entries that can be cached in a single TLB entry.
The contiguous bit is used to increase the mapping size at the pmd and pte
(last) level. So this type of HugeTLB page can be optimized only when its
size of the ``struct page`` structs is greater than **1** page.
Notice: The head vmemmap page is not freed to the buddy allocator and all
tail vmemmap pages are mapped to the head vmemmap page frame. So we can see
more than one ``struct page`` struct with ``PG_head`` (e.g. 8 per 2 MB HugeTLB
page) associated with each HugeTLB page. The ``compound_head()`` can handle
this correctly. There is only **one** head ``struct page``, the tail
``struct page`` with ``PG_head`` are fake head ``struct page``. We need an
approach to distinguish between those two different types of ``struct page`` so
that ``compound_head()`` can return the real head ``struct page`` when the
parameter is the tail ``struct page`` but with ``PG_head``.
Device DAX의 tail deduplication
185-231Device DAX
Device-DAX interface도 앞 절의 tail deduplication 기법을 사용하지만 device 자체의 vmemmap인 altmap을 사용할 때는 예외입니다.
DAX는 `PAGE_SIZE`(x86_64의 4KB), `PMD_SIZE`(2MB), `PUD_SIZE`(1GB)를 지원합니다. PowerPC의 대응 내용은 `Documentation/arch/powerpc/vmemmap_dedup.rst`를 참고하십시오.
HugeTLB와의 차이는 작습니다. Device DAX는 정보를 저장하는 데 4개가 아니라 3개의 `struct page`만 사용합니다.
Device-DAX memory는 boot 시 초기화되는 System RAM 범위가 아니므로 기존 vmemmap을 remap하지 않습니다. Section을 populate하는 더 늦은 단계에서 tail-page deduplication을 수행합니다.
HugeTLB는 head vmemmap page를 재사용하지만 Device DAX는 tail vmemmap page를 재사용합니다. 이 때문에 절약량은 HugeTLB의 절반뿐이며, deduplicate된 tail page는 read-only로 mapping하지 않습니다.
원문 마지막 구조에서 virtual `struct page` page 0과 1은 각각 physical frame 0과 1에 mapping되고, page 2부터 7은 모두 physical frame 2를 공유합니다.
Device DAX
==========
The device-dax interface uses the same tail deduplication technique explained
in the previous chapter, except when used with the vmemmap in
the device (altmap).
The following page sizes are supported in DAX: PAGE_SIZE (4K on x86_64),
PMD_SIZE (2M on x86_64) and PUD_SIZE (1G on x86_64).
For powerpc equivalent details see Documentation/arch/powerpc/vmemmap_dedup.rst
The differences with HugeTLB are relatively minor.
It only use 3 ``struct page`` for storing all information as opposed
to 4 on HugeTLB pages.
There's no remapping of vmemmap given that device-dax memory is not part of
System RAM ranges initialized at boot. Thus the tail page deduplication
happens at a later stage when we populate the sections. HugeTLB reuses the
the head vmemmap page representing, whereas device-dax reuses the tail
vmemmap page. This results in only half of the savings compared to HugeTLB.
Deduplicated tail pages are not mapped read-only.
Here's how things look like on device-dax after the sections are populated::
+-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
| | | 0 | -------------> | 0 |
| | +-----------+ +-----------+
| | | 1 | -------------> | 1 |
| | +-----------+ +-----------+
| | | 2 | ----------------^ ^ ^ ^ ^ ^
| | +-----------+ | | | | |
| | | 3 | ------------------+ | | | |
| | +-----------+ | | | |
| | | 4 | --------------------+ | | |
| PMD | +-----------+ | | |
| level | | 5 | ----------------------+ | |
| mapping | +-----------+ | |
| | | 6 | ------------------------+ |
| | +-----------+ |
| | | 7 | --------------------------+
| | +-----------+
| |
| |
| |
+-----------+
요약·해설
vmemmap_dedup.rst:1-231HVO는 HugeTLB의 tail `struct page`들이 사실상 같은 `compound_head`만 필요하다는 점을 이용합니다. 여러 vmemmap virtual page를 head backing frame 하나로 remap해 나머지 physical page를 buddy allocator에 돌리고, HugeTLB를 해제할 때 원래 mapping을 복원합니다. Device DAX는 section populate 시 tail frame을 공유해 같은 원리를 절반 수준의 절약으로 적용합니다.
원문 표의 base-page size와 지원 HugeTLB size를 구조화했습니다.
64-byte struct page와 8-byte page-table entry를 가정한 PMD·PUD 결과입니다.
원문의 첫 ASCII 구조처럼 vmemmap virtual page마다 별도 physical frame이 있습니다.
원문의 두 번째 ASCII 구조처럼 virtual slot은 유지하되 모두 head frame을 공유합니다.
두 방식의 deduplication 시점과 공유 대상을 비교합니다.
원문의 세 번째 ASCII 구조를 같은 mapping 관계로 표현했습니다.