요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
1
=============================
2
No-MMU memory mapping support
3
=============================
5
The kernel has limited support for memory mapping under no-MMU conditions, such
6
as are used in uClinux environments. From the userspace point of view, memory
7
mapping is made use of in conjunction with the mmap() system call, the shmat()
8
call and the execve() system call. From the kernel's point of view, execve()
9
mapping is actually performed by the binfmt drivers, which call back into the
10
mmap() routines to do the actual work.
12
Memory mapping behaviour also involves the way fork(), vfork(), clone() and
13
ptrace() work. Under uClinux there is no fork(), and clone() must be supplied
14
the CLONE_VM flag.
16
The behaviour is similar between the MMU and no-MMU cases, but not identical;
17
and it's also much more restricted in the latter case:
19
(#) Anonymous mapping, MAP_PRIVATE
21
In the MMU case: VM regions backed by arbitrary pages; copy-on-write
22
across fork.
24
In the no-MMU case: VM regions backed by arbitrary contiguous runs of
25
pages.
27
(#) Anonymous mapping, MAP_SHARED
29
These behave very much like private mappings, except that they're
30
shared across fork() or clone() without CLONE_VM in the MMU case. Since
31
the no-MMU case doesn't support these, behaviour is identical to
32
MAP_PRIVATE there.
34
(#) File, MAP_PRIVATE, PROT_READ / PROT_EXEC, !PROT_WRITE
36
In the MMU case: VM regions backed by pages read from file; changes to
37
the underlying file are reflected in the mapping; copied across fork.
39
In the no-MMU case:
41
- If one exists, the kernel will re-use an existing mapping to the
42
same segment of the same file if that has compatible permissions,
43
even if this was created by another process.
45
- If possible, the file mapping will be directly on the backing device
46
if the backing device has the NOMMU_MAP_DIRECT capability and
47
appropriate mapping protection capabilities. Ramfs, romfs, cramfs
48
and mtd might all permit this.
50
- If the backing device can't or won't permit direct sharing,
51
but does have the NOMMU_MAP_COPY capability, then a copy of the
52
appropriate bit of the file will be read into a contiguous bit of
53
memory and any extraneous space beyond the EOF will be cleared
55
- Writes to the file do not affect the mapping; writes to the mapping
56
are visible in other processes (no MMU protection), but should not
57
happen.
59
(#) File, MAP_PRIVATE, PROT_READ / PROT_EXEC, PROT_WRITE
61
In the MMU case: like the non-PROT_WRITE case, except that the pages in
62
question get copied before the write actually happens. From that point
63
on writes to the file underneath that page no longer get reflected into
64
the mapping's backing pages. The page is then backed by swap instead.
66
In the no-MMU case: works much like the non-PROT_WRITE case, except
67
that a copy is always taken and never shared.
69
(#) Regular file / blockdev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE
71
In the MMU case: VM regions backed by pages read from file; changes to
72
pages written back to file; writes to file reflected into pages backing
73
mapping; shared across fork.
75
In the no-MMU case: not supported.
77
(#) Memory backed regular file, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE
79
In the MMU case: As for ordinary regular files.
81
In the no-MMU case: The filesystem providing the memory-backed file
82
(such as ramfs or tmpfs) may choose to honour an open, truncate, mmap
83
sequence by providing a contiguous sequence of pages to map. In that
84
case, a shared-writable memory mapping will be possible. It will work
85
as for the MMU case. If the filesystem does not provide any such
86
support, then the mapping request will be denied.
88
(#) Memory backed blockdev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE
90
In the MMU case: As for ordinary regular files.
92
In the no-MMU case: As for memory backed regular files, but the
93
blockdev must be able to provide a contiguous run of pages without
94
truncate being called. The ramdisk driver could do this if it allocated
95
all its memory as a contiguous array upfront.
97
(#) Memory backed chardev, MAP_SHARED, PROT_READ / PROT_EXEC / PROT_WRITE
99
In the MMU case: As for ordinary regular files.
101
In the no-MMU case: The character device driver may choose to honour
102
the mmap() by providing direct access to the underlying device if it
103
provides memory or quasi-memory that can be accessed directly. Examples
104
of such are frame buffers and flash devices. If the driver does not
105
provide any such support, then the mapping request will be denied.
108
Further notes on no-MMU MMAP
109
============================
111
(#) A request for a private mapping of a file may return a buffer that is not
112
page-aligned. This is because XIP may take place, and the data may not be
113
paged aligned in the backing store.
115
(#) A request for an anonymous mapping will always be page aligned. If
116
possible the size of the request should be a power of two otherwise some
117
of the space may be wasted as the kernel must allocate a power-of-2
118
granule but will only discard the excess if appropriately configured as
119
this has an effect on fragmentation.
121
(#) The memory allocated by a request for an anonymous mapping will normally
122
be cleared by the kernel before being returned in accordance with the
123
Linux man pages (ver 2.22 or later).
125
In the MMU case this can be achieved with reasonable performance as
126
regions are backed by virtual pages, with the contents only being mapped
127
to cleared physical pages when a write happens on that specific page
128
(prior to which, the pages are effectively mapped to the global zero page
129
from which reads can take place). This spreads out the time it takes to
130
initialize the contents of a page - depending on the write-usage of the
131
mapping.
133
In the no-MMU case, however, anonymous mappings are backed by physical
134
pages, and the entire map is cleared at allocation time. This can cause
135
significant delays during a userspace malloc() as the C library does an
136
anonymous mapping and the kernel then does a memset for the entire map.
138
However, for memory that isn't required to be precleared - such as that
139
returned by malloc() - mmap() can take a MAP_UNINITIALIZED flag to
140
indicate to the kernel that it shouldn't bother clearing the memory before
141
returning it. Note that CONFIG_MMAP_ALLOW_UNINITIALIZED must be enabled
142
to permit this, otherwise the flag will be ignored.
144
uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this
145
to allocate the brk and stack region.
147
(#) A list of all the private copy and anonymous mappings on the system is
148
visible through /proc/maps in no-MMU mode.
150
(#) A list of all the mappings in use by a process is visible through
151
/proc/<pid>/maps in no-MMU mode.
153
(#) Supplying MAP_FIXED or a requesting a particular mapping address will
154
result in an error.
156
(#) Files mapped privately usually have to have a read method provided by the
157
driver or filesystem so that the contents can be read into the memory
158
allocated if mmap() chooses not to map the backing device directly. An
159
error will result if they don't. This is most likely to be encountered
160
with character device files, pipes, fifos and sockets.
163
Interprocess shared memory
164
==========================
166
Both SYSV IPC SHM shared memory and POSIX shared memory is supported in NOMMU
167
mode. The former through the usual mechanism, the latter through files created
168
on ramfs or tmpfs mounts.
171
Futexes
172
=======
174
Futexes are supported in NOMMU mode if the arch supports them. An error will
175
be given if an address passed to the futex system call lies outside the
176
mappings made by a process or if the mapping in which the address lies does not
177
support futexes (such as an I/O chardev mapping).
180
No-MMU mremap
181
=============
183
The mremap() function is partially supported. It may change the size of a
184
mapping, and may move it [#]_ if MREMAP_MAYMOVE is specified and if the new size
185
of the mapping exceeds the size of the slab object currently occupied by the
186
memory to which the mapping refers, or if a smaller slab object could be used.
188
MREMAP_FIXED is not supported, though it is ignored if there's no change of
189
address and the object does not need to be moved.
191
Shared mappings may not be moved. Shareable mappings may not be moved either,
192
even if they are not currently shared.
194
The mremap() function must be given an exact match for base address and size of
195
a previously mapped object. It may not be used to create holes in existing
196
mappings, move parts of existing mappings or resize parts of mappings. It must
197
act on a complete mapping.
199
.. [#] Not currently supported.
202
Providing shareable character device support
203
============================================
205
To provide shareable character device support, a driver must provide a
206
file->f_op->get_unmapped_area() operation. The mmap() routines will call this
207
to get a proposed address for the mapping. This may return an error if it
208
doesn't wish to honour the mapping because it's too long, at a weird offset,
209
under some unsupported combination of flags or whatever.
211
The driver should also provide backing device information with capabilities set
212
to indicate the permitted types of mapping on such devices. The default is
213
assumed to be readable and writable, not executable, and only shareable
214
directly (can't be copied).
216
The file->f_op->mmap() operation will be called to actually inaugurate the
217
mapping. It can be rejected at that point. Returning the ENOSYS error will
218
cause the mapping to be copied instead if NOMMU_MAP_COPY is specified.
220
The vm_ops->close() routine will be invoked when the last mapping on a chardev
221
is removed. An existing mapping will be shared, partially or not, if possible
222
without notifying the driver.
224
It is permitted also for the file->f_op->get_unmapped_area() operation to
225
return -ENOSYS. This will be taken to mean that this operation just doesn't
226
want to handle it, despite the fact it's got an operation. For instance, it
227
might try directing the call to a secondary driver which turns out not to
228
implement it. Such is the case for the framebuffer driver which attempts to
229
direct the call to the device-specific driver. Under such circumstances, the
230
mapping request will be rejected if NOMMU_MAP_COPY is not specified, and a
231
copy mapped otherwise.
233
.. important::
235
Some types of device may present a different appearance to anyone
236
looking at them in certain modes. Flash chips can be like this; for
237
instance if they're in programming or erase mode, you might see the
238
status reflected in the mapping, instead of the data.
240
In such a case, care must be taken lest userspace see a shared or a
241
private mapping showing such information when the driver is busy
242
controlling the device. Remember especially: private executable
243
mappings may still be mapped directly off the device under some
244
circumstances!
247
Providing shareable memory-backed file support
248
==============================================
250
Provision of shared mappings on memory backed files is similar to the provision
251
of support for shared mapped character devices. The main difference is that the
252
filesystem providing the service will probably allocate a contiguous collection
253
of pages and permit mappings to be made on that.
255
It is recommended that a truncate operation applied to such a file that
256
increases the file size, if that file is empty, be taken as a request to gather
257
enough pages to honour a mapping. This is required to support POSIX shared
258
memory.
260
Memory backed devices are indicated by the mapping's backing device info having
261
the memory_backed flag set.
264
Providing shareable block device support
265
========================================
267
Provision of shared mappings on block device files is exactly the same as for
268
character devices. If there isn't a real device underneath, then the driver
269
should allocate sufficient contiguous memory to honour any supported mapping.
272
Adjusting page trimming behaviour
273
=================================
275
NOMMU mmap automatically rounds up to the nearest power-of-2 number of pages
276
when performing an allocation. This can have adverse effects on memory
277
fragmentation, and as such, is left configurable. The default behaviour is to
278
aggressively trim allocations and discard any excess pages back in to the page
279
allocator. In order to retain finer-grained control over fragmentation, this
280
behaviour can either be disabled completely, or bumped up to a higher page
281
watermark where trimming begins.
283
Page trimming behaviour is configurable via the sysctl ``vm.nr_trim_pages``.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
No-MMU mapping 개요
1-18Kernel은 uClinux 같은 no-MMU 환경에서 제한적인 memory mapping을 지원합니다. User space에서는 mmap(), shmat(), execve()가 mapping을 사용합니다. Kernel 관점에서 execve() mapping은 binfmt driver가 mmap() routine을 callback하여 실제 작업을 수행합니다.
Memory mapping 동작은 fork(), vfork(), clone(), ptrace() 방식과도 연결됩니다. uClinux에는 fork()가 없고 clone()에는 CLONE_VM flag를 반드시 제공해야 합니다. MMU와 no-MMU의 동작은 비슷하지만 같지 않으며 no-MMU 쪽 제약이 훨씬 큽니다.
Anonymous mapping
19-33| 유형 | MMU | No-MMU |
|---|---|---|
| Anonymous MAP_PRIVATE | 임의의 page로 구성한 VM region, fork() 사이 copy-on-write | 임의의 연속된 page run으로 구성한 VM region |
| Anonymous MAP_SHARED | private mapping과 비슷하지만 fork() 또는 CLONE_VM 없는 clone() 사이에서 공유 | 그런 process 생성 방식을 지원하지 않으므로 MAP_PRIVATE과 동일 |
No-MMU의 anonymous mapping은 임의의 page를 흩어 배치할 수 없고 contiguous run이 필요합니다. 또한 fork()나 CLONE_VM 없는 clone()을 지원하지 않으므로 MAP_SHARED와 MAP_PRIVATE의 차이가 없습니다.
Read/execute private file mapping
34-58File을 MAP_PRIVATE, PROT_READ 또는 PROT_EXEC, !PROT_WRITE로 mapping할 때 MMU에서는 file에서 읽은 page가 VM region을 backing하고 underlying file의 변경이 mapping에 반영되며 fork()에서 복사됩니다.
No-MMU에서는 다음 우선순위와 가시성 규칙을 사용합니다.
| 경로 | No-MMU 동작 |
|---|---|
| 기존 mapping 재사용 | 같은 file segment에 permission-compatible mapping이 있으면 다른 process가 만든 것도 재사용 |
| 직접 mapping | backing device가 NOMMU_MAP_DIRECT와 적절한 protection capability를 가지면 device에 직접 mapping. ramfs, romfs, cramfs, mtd가 허용할 수 있음 |
| copy mapping | 직접 공유할 수 없지만 NOMMU_MAP_COPY가 있으면 file 부분을 contiguous memory로 읽고 EOF 뒤 여분 공간을 clear |
| 변경 가시성 | file write는 mapping에 반영되지 않음. MMU 보호가 없어서 mapping write는 다른 process에 보이지만 발생해서는 안 됨 |
Writable private file mapping
59-68MMU에서 PROT_WRITE가 있는 private file mapping은 쓰기 직전에 대상 page를 복사합니다. 그 뒤 underlying file write는 그 page의 backing page에 더 이상 반영되지 않고, page는 swap으로 backing됩니다.
No-MMU에서는 !PROT_WRITE 사례와 비슷하지만 항상 copy를 만들고 절대 공유하지 않습니다.
No-MMU mmap 추가 제약
106-161| 항목 | 동작·제약 |
|---|---|
| Private file 정렬 | XIP와 backing-store 정렬 때문에 반환 buffer가 page-aligned가 아닐 수 있음 |
| Anonymous 정렬·크기 | 항상 page-aligned. power-of-two가 아니면 kernel의 power-of-2 granule 할당과 trimming 구성에 따라 공간 낭비·fragmentation 발생 |
| Anonymous 초기화 | 일반적으로 반환 전에 전체 physical map을 clear하므로 malloc() 시 C library mmap과 kernel memset이 큰 지연을 만들 수 있음 |
| MAP_UNINITIALIZED | preclear가 필요 없는 memory는 clear를 생략할 수 있으나 CONFIG_MMAP_ALLOW_UNINITIALIZED가 켜져야 함 |
| /proc/maps | system의 모든 private-copy 및 anonymous mapping 표시 |
| /proc/<pid>/maps | 해당 process가 사용하는 모든 mapping 표시 |
| 고정 주소·read method | MAP_FIXED 또는 특정 주소 요청은 오류. Private file을 direct mapping하지 못하면 driver/filesystem read method가 필요 |
Linux man pages (ver 2.22 or later)에 따라 anonymous mapping memory는 일반적으로 반환 전에 kernel이 clear합니다. MMU에서는 anonymous region이 virtual page로 backing되고 실제 write가 일어날 때 clear된 physical page를 붙입니다. 그전에는 global zero page에서 읽을 수 있어 초기화 비용이 write 사용량에 따라 분산됩니다.
No-MMU에서는 anonymous mapping 전체가 physical page로 backing되므로 할당 시 map 전체를 clear합니다. MAP_UNINITIALIZED는 malloc()처럼 preclear가 필요 없는 memory에서 이 비용을 피합니다. uClibc는 malloc() 가속에, ELF-FDPIC binfmt는 brk와 stack region 할당에 사용합니다.
CONFIG_MMAP_ALLOW_UNINITIALIZED가 꺼져 있으면 MAP_UNINITIALIZED flag는 무시됩니다. 초기화되지 않은 memory 노출의 security 영향을 검토해야 합니다.
Private file mapping을 device에 직접 붙이지 못하면 내용을 할당 memory로 읽을 read method가 driver 또는 filesystem에 있어야 합니다. 없으면 오류가 나며 chardev, pipe, fifo, socket에서 만날 가능성이 큽니다.
Shared memory와 futex
162-178NOMMU mode는 SYSV IPC SHM과 POSIX shared memory를 모두 지원합니다. 전자는 일반 mechanism을 사용하고 후자는 ramfs 또는 tmpfs mount에 만든 file을 사용합니다.
Architecture가 지원하면 futex도 사용할 수 있습니다. futex system call에 넘긴 address가 process mapping 밖에 있거나, 그 address가 속한 mapping이 I/O chardev mapping처럼 futex를 지원하지 않으면 오류가 반환됩니다.
No-MMU mremap
179-200mremap()은 일부만 지원합니다. mapping 크기는 바꿀 수 있고 MREMAP_MAYMOVE가 지정되며 새 크기가 현재 slab object보다 크거나 더 작은 slab object를 쓸 수 있으면 이동할 수 있다고 정의되어 있지만, 각주에 따르면 이동은 현재 지원되지 않습니다.
| 기능 | 제약 |
|---|---|
| resize | mapping 크기를 바꿀 수 있고 조건에 따라 MREMAP_MAYMOVE로 이동할 수 있지만 이동은 현재 미지원 |
| MREMAP_FIXED | 지원하지 않음. 주소가 변하지 않고 object를 이동할 필요가 없으면 무시 |
| shared/shareable | 현재 공유 여부와 관계없이 shared 또는 shareable mapping은 이동 불가 |
| 정확한 전체 mapping | 기존 object의 base address와 size가 정확히 일치해야 하며 hole 생성, 일부 이동·resize는 불가 |
mremap()에는 이전에 mapping한 object의 base address와 size를 정확히 넘겨야 합니다. Existing mapping에 hole을 만들거나 일부만 이동·resize할 수 없으며 항상 complete mapping 전체에 작동해야 합니다.
Shareable memory-backed file 지원
247-263Memory-backed file의 shared mapping 지원은 shared-mapped chardev와 비슷합니다. 주된 차이는 service를 제공하는 filesystem이 contiguous page collection을 할당하고 그 위에 mapping을 허용할 가능성이 크다는 점입니다.
빈 file의 크기를 늘리는 truncate는 mapping을 만족할 충분한 page를 모으라는 요청으로 처리하는 것이 권장됩니다. POSIX shared memory를 지원하려면 이 동작이 필요합니다. Memory-backed device는 mapping의 backing device info에 memory_backed flag를 설정해 표시합니다.
Page trimming 조정
272-283NOMMU mmap은 allocation할 때 page 수를 가장 가까운 상위 power-of-2로 자동 반올림합니다. 이는 memory fragmentation에 불리할 수 있어 구성 가능하게 되어 있습니다.
기본 동작은 allocation을 적극적으로 trim하고 excess page를 page allocator에 돌려줍니다. Fragmentation을 더 세밀하게 제어하려면 trimming을 완전히 끄거나 trimming을 시작할 더 높은 page watermark를 지정할 수 있습니다. 이 동작은 sysctl vm.nr_trim_pages로 구성합니다.
운영 핵심
nommu-mmap.rst:1-283No-MMU mapping은 virtual-memory remapping 대신 contiguous physical memory와 device capability에 의존합니다. Mapping flag만 볼 것이 아니라 filesystem·driver의 direct/copy 지원, page 초기화 비용, 이동 제한과 trimming 정책을 함께 검토해야 합니다.