admin-guide/mm/transhuge.rst

16 But in the future it can expand to other filesystems.
26 requiring larger clear-page copy-page in page faults which is a
32 factor will affect all subsequent accesses to the memory for the whole
44    hugepages but a significant speedup already happens if only one of
46    going to run faster.
48 THP can be enabled system wide or restricted to certain tasks or even
57 if compared to the reservation approach of hugetlbfs by allowing all
58 unused memory to be used as cache or other movable (or even unmovable
59 entities). It doesn't require reservation to prevent hugepage
60 allocation failures to be noticeable from userland. It allows paging
61 and all other advanced VM features to be available on the
62 hugepages. It requires no modifications for applications to take
65 Applications however can be further optimized to take advantage of
66 this feature, like for example they've been optimized before to avoid
76 possible to disable hugepages system-wide and to only have them inside
80 to eliminate any risk of wasting any precious byte of memory and to
84 risk to lose memory by using hugepages, should use
93 -------------------
97 regions (to avoid the risk of consuming more memory resources) or enabled
98 system wide. This can be achieved with one of::
104 It's also possible to limit defrag efforts in the VM to generate
105 anonymous hugepages in case they're not immediately free to madvise
106 regions or to never try to defrag memory and simply fallback to regular
108 time to defrag memory, we would expect to gain even more by the fact we
124 	memory in an effort to allocate a THP immediately. This may be
126 	use and are willing to delay the VM start to utilise them.
130 	to reclaim pages and wake kcompactd to compact memory so that
132 	of khugepaged to then install the THP pages later.
137 	other regions will wake kswapd in the background to reclaim
138 	pages and wake kcompactd to compact memory so that THP is
147 	should be self-explanatory.
149 By default kernel tries to use huge zero page on read page fault to
150 anonymous mapping. It's possible to disable huge zero page by writing 0
157 library) may want to know the size (in bytes) of a transparent hugepage::
162 transparent_hugepage/enabled is set to "always" or "madvise, and it'll
163 be automatically shutdown if it's set to "never".
166 -------------------
168 khugepaged runs usually at low frequency so while one may not want to
171 also possible to disable defrag in khugepaged by writing 0 or enable
177 You can also control how many pages khugepaged should scan at each
182 and how many milliseconds to wait in khugepaged between each pass (you
183 can set this to 0 to run khugepaged at 100% utilization of one core)::
187 and how many milliseconds to wait in khugepaged if there's an hugepage
188 allocation failure to throttle the next allocation attempt::
196 one 2M hugepage. Each may happen independently, or together, depending on
207 ``max_ptes_none`` specifies how many extra small pages (that are
209 of small pages into one large page::
213 A higher value leads to use additional memory for programs.
214 A lower value leads to gain less thp performance. Value of
218 ``max_ptes_swap`` specifies how many pages can be brought in from
228 ``max_ptes_shared`` specifies how many pages can be shared across multiple
241 to the kernel command line.
250     Attempt to allocate huge pages every time we need a new page;
264 ``mount -o remount,huge= /mountpoint`` works fine after mount: remounting
265 ``huge=never`` will not attempt to break up huge pages at all, just stop more
268 There's also sysfs knob to control hugepage allocation policy for internal
273 In addition to policies listed above, shmem_enabled allows two further
277     For use in emergencies, to force the huge option off from
280     Force the huge option on for all - very useful for testing;
286 future behavior. So to make them effective you need to restart any
287 application that could have been using hugepages. This also applies to the
295 To identify what applications are using anonymous transparent huge pages,
296 it is necessary to read ``/proc/PID/smaps`` and count the AnonHugePages fields
299 The number of file transparent huge pages mapped to userspace is available
301 To identify what applications are mapping file transparent huge pages, it
302 is necessary to read ``/proc/PID/smaps`` and count the FileHugeMapped fields
308 There are a number of counters in ``/proc/vmstat`` that may be used to
313 	allocated to handle a page fault.
317 	a range of pages to collapse into one huge page and has
318 	successfully allocated a new huge page to store the data.
321 	is incremented if a page fault fails to allocate
322 	a huge page and instead falls back to using small pages.
325 	is incremented if a page fault fails to charge a huge page and
326 	instead falls back to using small pages even though the
331 	of pages that should be collapsed into one huge page but failed
339 	is incremented if a file huge page is attempted to be allocated
340 	but fails and instead falls back to using small pages.
344 	falls back to using small pages even though the allocation was
358 	is incremented if kernel fails to split huge
365 	going to be split under memory pressure.
379 	is incremented if kernel fails to allocate
380 	huge zero page and falls back to using small pages.
383 	is incremented every time a huge page is swapout in one
387 	is incremented if a huge page has to be split before swapout.
388 	Usually because failed to allocate some continuous swap space
392 system uses memory compaction to copy data around memory to free a
393 huge page for use. There are some counters in ``/proc/vmstat`` to help
397 	is incremented every time a process stalls to run
405 	is incremented if the system tries to compact memory
408 It is possible to establish how long the stalls were using the function
409 tracer to record how long was spent in __alloc_pages() and
410 using the mm_page_alloc tracepoint to identify which allocations were
416 To be guaranteed that the kernel will map a 2M page immediately in any
417 memory region, the mmap region has to be hugepage naturally
426 usual features belonging to hugetlbfs are preserved and