xref: /freebsd/share/man/man9/vm_page_alloc.9 (revision 7fdf597e96a02165cfe22ff357b857d5fa15ed8a)
1.\"
2.\" Copyright (C) 2001 Chad David <davidc@acns.ab.ca>. All rights reserved.
3.\" Copyright (c) 2021 The FreeBSD Foundation
4.\"
5.\" Portions of this documentation were written by Mark Johnston under
6.\" sponsorship from the FreeBSD Foundation.
7.\"
8.\" Redistribution and use in source and binary forms, with or without
9.\" modification, are permitted provided that the following conditions
10.\" are met:
11.\" 1. Redistributions of source code must retain the above copyright
12.\"    notice(s), this list of conditions and the following disclaimer as
13.\"    the first lines of this file unmodified other than the possible
14.\"    addition of one or more copyright notices.
15.\" 2. Redistributions in binary form must reproduce the above copyright
16.\"    notice(s), this list of conditions and the following disclaimer in the
17.\"    documentation and/or other materials provided with the distribution.
18.\"
19.\" THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER(S) ``AS IS'' AND ANY
20.\" EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
21.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
22.\" DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) BE LIABLE FOR ANY
23.\" DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
24.\" (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
25.\" SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
26.\" CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
27.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
28.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
29.\" DAMAGE.
30.\"
31.Dd August 4, 2024
32.Dt VM_PAGE_ALLOC 9
33.Os
34.Sh NAME
35.Nm vm_page_alloc
36.Nd "allocate a page of memory"
37.Sh SYNOPSIS
38.In sys/param.h
39.In vm/vm.h
40.In vm/vm_page.h
41.Ft vm_page_t
42.Fn vm_page_alloc "vm_object_t object" "vm_pindex_t pindex" "int req"
43.Ft vm_page_t
44.Fo vm_page_alloc_after
45.Fa "vm_object_t object"
46.Fa "vm_pindex_t pindex"
47.Fa "int req"
48.Fa "vm_page_t mpred"
49.Fc
50.Ft vm_page_t
51.Fo vm_page_alloc_contig
52.Fa "vm_object_t object"
53.Fa "vm_pindex_t pindex"
54.Fa "int req"
55.Fa "u_long npages"
56.Fa "vm_paddr_t low"
57.Fa "vm_paddr_t high"
58.Fa "u_long alignment"
59.Fa "vm_paddr_t boundary"
60.Fa "vm_memattr_t memattr"
61.Fc
62.Ft vm_page_t
63.Fo vm_page_alloc_contig_domain
64.Fa "vm_object_t object"
65.Fa "vm_pindex_t pindex"
66.Fa "int req"
67.Fa "u_long npages"
68.Fa "vm_paddr_t low"
69.Fa "vm_paddr_t high"
70.Fa "u_long alignment"
71.Fa "vm_paddr_t boundary"
72.Fa "vm_memattr_t memattr"
73.Fc
74.Ft vm_page_t
75.Fo vm_page_alloc_domain
76.Fa "vm_object_t object"
77.Fa "vm_pindex_t pindex"
78.Fa "int domain"
79.Fa "int req"
80.Fc
81.Ft vm_page_t
82.Fo vm_page_alloc_domain_after
83.Fa "vm_object_t object"
84.Fa "vm_pindex_t pindex"
85.Fa "int domain"
86.Fa "int req"
87.Fa "vm_page_t mpred"
88.Fc
89.Ft vm_page_t
90.Fo vm_page_alloc_noobj
91.Fa "int req"
92.Fc
93.Ft vm_page_t
94.Fo vm_page_alloc_noobj_contig
95.Fa "int req"
96.Fa "u_long npages"
97.Fa "vm_paddr_t low"
98.Fa "vm_paddr_t high"
99.Fa "u_long alignment"
100.Fa "vm_paddr_t boundary"
101.Fa "vm_memattr_t memattr"
102.Fc
103.Ft vm_page_t
104.Fo vm_page_alloc_noobj_contig_domain
105.Fa "int domain"
106.Fa "int req"
107.Fa "u_long npages"
108.Fa "vm_paddr_t low"
109.Fa "vm_paddr_t high"
110.Fa "u_long alignment"
111.Fa "vm_paddr_t boundary"
112.Fa "vm_memattr_t memattr"
113.Fc
114.Ft vm_page_t
115.Fo vm_page_alloc_noobj_domain
116.Fa "int domain"
117.Fa "int req"
118.Fc
119.Sh DESCRIPTION
120The
121.Fn vm_page_alloc
122family of functions allocate one or more pages of physical memory.
123Most kernel code should not call these functions directly but should instead
124use a kernel memory allocator such as
125.Xr malloc 9
126or
127.Xr uma 9 ,
128or should use a higher-level interface to the page cache, such as
129.Xr vm_page_grab 9 .
130.Pp
131All of the functions take a
132.Fa req
133parameter which encodes the allocation priority and optional modifier flags,
134described below.
135The functions whose names do not include
136.Dq noobj
137additionally insert the pages starting at index
138.Fa pindex
139in the
140VM object
141.Fa object .
142The object must be write-locked and not have a page already resident at the
143specified index.
144The functions whose names include
145.Dq domain
146support NUMA-aware allocation by returning pages from the
147.Xr numa 4
148domain specified by
149.Fa domain .
150.Pp
151The
152.Fn vm_page_alloc_after
153and
154.Fn vm_page_alloc_domain_after
155functions behave identically to
156.Fn vm_page_alloc
157and
158.Fn vm_page_alloc_domain ,
159respectively, except that they take an additional parameter
160.Fa mpred
161which must be the page resident in
162.Fa object
163with largest index smaller than
164.Fa pindex ,
165or
166.Dv NULL
167if no such page exists.
168These functions exist to optimize the common case of loops that allocate
169multiple pages at successive indices within an object.
170.Pp
171The
172.Fn vm_page_alloc_contig
173and
174.Fn vm_page_alloc_noobj_contig
175functions and their NUMA-aware variants allocate a physically contiguous run of
176.Fa npages
177pages which satisfies the specified constraints.
178The
179.Fa low
180and
181.Fa high
182parameters specify a physical address range from which the run is to
183be allocated.
184The
185.Fa alignment
186parameter specifies the requested alignment of the first page in the run
187and must be a power of two.
188If the
189.Fa boundary
190parameter is non-zero, the pages constituting the run will not cross a
191physical address that is a multiple of the parameter value, which must be a
192power of two.
193If
194.Fa memattr
195is not equal to
196.Dv VM_MEMATTR_DEFAULT ,
197then mappings of the returned pages created by, e.g.,
198.Xr pmap_enter 9
199or
200.Xr pmap_qenter 9 ,
201will carry the machine-dependent encoding of the memory attribute.
202Additionally, the direct mapping of the page, if any, will be updated to
203reflect the requested memory attribute.
204.Sh REQUEST FLAGS
205All page allocator functions accept a
206.Fa req
207parameter that governs certain aspects of the function's behavior.
208.Pp
209The
210.Dv VM_ALLOC_WAITOK ,
211.Dv VM_ALLOC_WAITFAIL ,
212and
213.Dv VM_ALLOC_NOWAIT
214flags specify the behavior of the allocator if free pages could not be
215immediately allocated.
216The
217.Dv VM_ALLOC_WAITOK
218flag can only be used with the
219.Dq noobj
220variants.
221If
222.Dv VM_ALLOC_NOWAIT
223is specified, then the allocator gives up and returns
224.Dv NULL .
225.Dv VM_ALLOC_NOWAIT
226is specified implicitly if none of the flags are present in the request.
227If either
228.Dv VM_ALLOC_WAITOK
229or
230.Dv VM_ALLOC_WAITFAIL
231is specified, the allocator will put the calling thread to sleep until
232sufficient free pages become available.
233At this point, if
234.Dv VM_ALLOC_WAITFAIL
235is specified the allocator will return
236.Dv NULL ,
237and if
238.Dv VM_ALLOC_WAITOK
239is specified the allocator will retry the allocation.
240After a failed
241.Dv VM_ALLOC_WAITFAIL
242allocation returns, the VM object, if any, will have been unlocked while the
243thread was sleeping.
244In this case the VM object write lock will be re-acquired before the function
245call returns.
246.Pp
247.Fa req
248also encodes the allocation request priority.
249By default the page(s) are allocated with no special treatment.
250If the number of available free pages is below a certain watermark, the
251allocation will fail or the allocating thread will sleep, depending on
252the specified wait flag.
253The watermark is computed at boot time and corresponds to a small (less than
254one percent) fraction of the system's total physical memory.
255To allocate memory more aggressively, one of following flags may be specified.
256.Bl -tag -width ".Dv VM_ALLOC_INTERRUPT"
257.It Dv VM_ALLOC_SYSTEM
258The page can be allocated if the free page count is above the interrupt
259reserved water mark.
260This flag should be used only when the system really needs the page.
261.It Dv VM_ALLOC_INTERRUPT
262The allocation will fail only if zero free pages are available.
263This flag should be used only if the consequences of an allocation failure
264are worse than leaving the system without free memory.
265For example, this flag is used when allocating kernel page table pages, where
266allocation failures trigger a kernel panic.
267.El
268.Pp
269The following optional flags can further modify allocator behavior:
270.Bl -tag -width ".Dv VM_ALLOC_NOBUSY"
271.It Dv VM_ALLOC_SBUSY
272The returned page will be shared-busy.
273This flag may only be specified when allocating pages in a VM object.
274.It Dv VM_ALLOC_NOBUSY
275The returned page will not be busy.
276This flag is implicit when allocating pages without a VM object.
277When allocating pages in a VM object, and neither
278.Dv VM_ALLOC_SBUSY
279nor
280.Dv VM_ALLOC_NOBUSY
281are specified, the returned pages will be exclusively busied.
282.It Dv VM_ALLOC_NODUMP
283The returned page will not be included in any kernel core dumps
284regardless of whether or not it is mapped in to KVA.
285.It Dv VM_ALLOC_WIRED
286The returned page will be wired.
287.It Dv VM_ALLOC_ZERO
288If this flag is specified, the
289.Dq noobj
290variants will return zeroed pages.
291The other allocator interfaces ignore this flag.
292.It Dv VM_ALLOC_NORECLAIM
293If this flag is specified and the request can not be immediately satisfied,
294the allocator will not attempt to break superpage reservations to satisfy the
295allocation.
296This may be useful when the overhead of scanning the reservation queue
297outweighs the cost of a failed allocation.
298This flag may be used only with the
299.Dq contig
300variants, and must not be specified in combination with
301.Dv VM_ALLOC_WAITOK .
302.It Dv VM_ALLOC_COUNT(n)
303Hint that at least
304.Fa n
305pages will be allocated by the caller in the near future.
306.Fa n
307must be no larger than 65535.
308If the system is short of free pages, this hint may cause the kernel
309to reclaim memory more aggressively than it would otherwise.
310.It Dv VM_ALLOC_NOFREE
311The caller asserts that the returned page will never be released.
312If this flag is specified, the allocator will try to fetch a page from a
313special per-domain arena in order to curb long-term physical memory fragmentation.
314.El
315.Sh RETURN VALUES
316If the allocation was successful, a pointer to the
317.Vt struct vm_page
318corresponding to the allocated page is returned.
319If the allocation request specified multiple pages, the returned
320pointer points to an array of
321.Vt struct vm_page
322constituting the run.
323Upon failure,
324.Dv NULL
325is returned.
326Regardless of whether the allocation succeeds or fails, the VM
327object
328.Fa object
329will be write-locked upon return.
330.Sh SEE ALSO
331.Xr numa 4 ,
332.Xr malloc 9 ,
333.Xr uma 9 ,
334.Xr vm_page_grab 9 ,
335.Xr vm_page_sbusy 9
336.Sh AUTHORS
337This manual page was written by
338.An Chad David Aq Mt davidc@acns.ab.ca .
339