1 .\" Copyright (c) 1991, 1993
2 .\" The Regents of the University of California. All rights reserved.
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\" notice, this list of conditions and the following disclaimer.
9 .\" 2. Redistributions in binary form must reproduce the above copyright
10 .\" notice, this list of conditions and the following disclaimer in the
11 .\" documentation and/or other materials provided with the distribution.
12 .\" 3. All advertising materials mentioning features or use of this software
13 .\" must display the following acknowledgement:
14 .\" This product includes software developed by the University of
15 .\" California, Berkeley and its contributors.
16 .\" 4. Neither the name of the University nor the names of its contributors
17 .\" may be used to endorse or promote products derived from this software
18 .\" without specific prior written permission.
20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
32 .\" @(#)mmap.2 8.4 (Berkeley) 5/11/95
40 .Nd allocate memory, or map files or devices into memory
44 .Fd #include <sys/types.h>
45 .Fd #include <sys/mman.h>
47 .Fn mmap "void *addr" "size_t len" "int prot" "int flags" "int fd" "off_t offset"
51 function causes the pages starting at
53 and continuing for at most
55 bytes to be mapped from the object described by
57 starting at byte offset
61 is not a multiple of the pagesize, the mapped region may extend past the
63 Any such extension beyond the end of the mapped object will be zero-filled.
67 is non-zero, it is used as a hint to the system.
68 (As a convenience to the system, the actual address of the region may differ
69 from the address supplied.)
72 is zero, an address will be selected by the system.
73 The actual starting address of the region is returned.
76 deletes any previous mapping in the allocated address range.
78 The protections (region accessibility) are specified in the
84 .Bl -tag -width PROT_WRITE -compact
86 Pages may not be accessed.
92 Pages may be executed.
97 parameter specifies the type of the mapped object, mapping options and
98 whether modifications made to the mapped copy of the page are private
99 to the process or are to be shared with other references.
100 Sharing, mapping type and options are specified in the
104 the following values:
105 .Bl -tag -width MAP_HASSEMAPHORE
107 Map anonymous memory not associated with any specific file.
108 The file descriptor used for creating
113 parameter is ignored.
115 .\"Mapped from a regular file or character-special device memory.
117 Do not permit the system to select a different address than the one
119 If the specified address cannot be used,
126 must be a multiple of the pagesize.
127 Use of this option is discouraged.
128 .It Dv MAP_HASSEMAPHORE
129 Notify the kernel that the region may contain semaphores and that special
130 handling may be necessary.
132 Permit regions to be inherited across
136 Region is not included in a core file.
138 Causes data dirtied via this VM map to be flushed to physical media
139 only when necessary (usually by the pager) rather then gratuitously.
140 Typically this prevents the update daemons from flushing pages dirtied
141 through such maps and thus allows efficient sharing of memory across
142 unassociated processes using a file-backed shared memory map. Without
143 this option any VM pages you dirty may be flushed to disk every so often
144 (every 30-60 seconds usually) which can create performance problems if you
145 do not need that to occur (such as when you are using shared file-backed
146 mmap regions for IPC purposes). Note that VM/filesystem coherency is
147 maintained whether you use
149 or not. This option is not portable
152 platforms (yet), though some may implement the same behavior
156 Extending a file with
158 thus creating a big hole, and then filling the hole by modifying a shared
160 can lead to severe file fragmentation.
161 In order to avoid such fragmentation you should always pre-allocate the
162 file's backing store by
164 zero's into the newly extended area prior to modifying the area via your
166 The fragmentation problem is especially sensitive to
168 pages, because pages may be flushed to disk in a totally random order.
170 The same applies when using
172 to implement a file-based shared memory store.
173 It is recommended that you create the backing store by
175 zero's to the backing file rather then
178 You can test file fragmentation by observing the KB/t (kilobytes per
179 transfer) results from an
181 while reading a large file sequentially, e.g. using
182 .Dq Li dd if=filename of=/dev/null bs=32k .
186 function will flush all dirty data and metadata associated with a file,
187 including dirty NOSYNC VM data, to physical media. The
191 system call generally do not flush dirty NOSYNC VM data.
194 system call is obsolete since
196 implements a coherent filesystem buffer cache. However, it may be
197 used to associate dirty VM pages with filesystem buffers and thus cause
198 them to be flushed to physical media sooner rather then later.
200 Modifications are private.
202 Modifications are shared.
204 This option is only available if your system has been compiled with
206 defined when compiling the kernel.
207 This is the default for
215 to enable this option for other architechures.
225 must include at least
230 a memory region that grows to at most
232 bytes in size, starting from the stack top and growing down. The
233 stack top is the starting address returned by the call, plus
235 bytes. The bottom of the stack at maximum growth is the starting
236 address returned by the call.
241 function does not unmap pages, see
243 for further information.
245 The current design does not allow a process to specify the location of
247 In the future we may define an additional mapping type,
250 the file descriptor argument specifies a file or device to which swapping
253 Upon successful completion,
255 returns a pointer to the mapped region.
256 Otherwise, a value of
260 is set to indicate the error.
268 was specified as part of the
272 was not open for reading.
277 were specified as part of the
283 was not open for writing.
286 is not a valid open file descriptor.
289 was specified and the
291 parameter was not page aligned, or part of the desired address space
292 resides out of the valid address space for a user process.
298 was specified and the
300 parameter was not -1.
303 has not been specified and
305 did not reference a regular or character special file.
308 was not page-aligned.
314 was specified and the
316 parameter wasn't available, or the system has reached the per-process mmap
317 limit specified in the
321 was specified and insufficient memory was available.
334 is limited to 2GB. Mmapping slightly more than 2GB doesn't work, but
335 it is possible to map a window of size (filesize % 2GB) for file sizes
336 of slightly less than 2G, 4GB, 6GB and 8GB.
338 The limit is imposed for a variety of reasons.
339 Most of them have to do
342 not wanting to use 64 bit offsets in the VM system due to
343 the extreme performance penalty.
346 uses 32bit page indexes and
349 a maximum of 8TB filesizes.
350 It's actually bugs in
351 the filesystem code that causes the limit to be further restricted to
352 1TB (loss of precision when doing blockno calculations).
354 Another reason for the 2GB limit is that filesystem metadata can
355 reside at negative offsets.
357 We currently can only deal with page aligned file offsets.