Lines Matching full:are
10 Huge pages as described at :ref:`hugetlbpage` are typically
11 preallocated for application use. These huge pages are instantiated in a
12 task's address space at page fault time if the VMA indicates huge pages are
28 This description is primarily targeted at kernel developers who are modifying
37 huge pages are only available to the task which reserved them.
62 The 'from' and 'to' fields of the file region structure are huge page
67 These are stored in the bottom bits of the reservation map pointer.
89 of mappings. Location differences are:
95 inode->i_mapping->private_data. Since shared mappings are always backed
103 Reservations are created when a huge page backed shared memory segment is
115 are desired.
117 The arguments 'from' and 'to' are huge page indices into the mapping or
124 in which reservations are represented in the reservation map.
127 exists or did exist for the corresponding page. As reservations are
130 a reservation exists for the corresponding page. As reservations are
131 consumed, entries are added to the reservation map. Therefore, the
140 are needed for the current mapping/segment. For private mappings, this is
156 are enough free huge pages to accommodate the reservation. If there are,
170 mappings, no modifications are made to the reservation map as lack of an
182 Reservations are consumed when huge pages associated with the reservations
183 are allocated and instantiated in the corresponding mapping. The allocation
195 page are being allocated.
212 - chg, even though this argument is of type long only the values 0 or 1 are
218 The free lists associated with the memory policy of the VMA are searched for
221 associated with the page, the following adjustments are made::
255 a race is detected, the subpool and global reserve counts are adjusted to
265 of the allocating task. Before this, pages in a shared mapping are added
266 to the page cache and pages in private mappings are added to an anonymous
286 for information on how these are set).
290 indicates reserves are associated with the subpool, and this newly free page
310 min_size are reserved for use by the filesystem. This number is tracked in
315 The routines hugepage_subpool_get/put_pages() are called when pages are
318 hugepage_subpool_get/put_pages are passed the number of huge pages by which
323 However, if reserves are associated with the subpool a return value less
345 COW, it is possible that no free huge pages are free and the allocation
372 The following low level routines are used to make modifications to a
373 reservation map. Typically, these routines are not called directly. Rather,
375 routines. These low level routines are fairly well documented in the source
376 code (mm/hugetlb.c). These routines are::
386 many pages in the specified range [f, t) are NOT currently represented.
389 there are enough huge pages for the operation to succeed.
399 are guaranteed to succeed after a prior call to region_chg() for the same
405 which are NOT currently represented in the map. This number is returned to
428 are removed from the middle of the file one at a time. As the pages are
447 reservation map we know how many reservations were consumed and how many are
450 are decremented by the number of outstanding reservations.
458 These routines are only interested with reservations for a specific huge
516 map modifications are performed in two steps. First vma_needs_reservation
519 Global and subpool reservation counts are adjusted based on success or failure
525 However, there are several instances where errors are encountered after a huge
559 into account. While cpusets are not exactly the same as memory policy, this
584 available on the required nodes. This is true even if there are a sufficient
590 The most complete set of hugetlb tests are in the libhugetlbfs repository.