admin-guide/mm/transhuge.rst

11 using huge pages for the backing of virtual memory with huge pages
20    the huge page size is 2M, although the actual numbers may vary
51 collapses sequences of basic pages into huge pages.
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
219 swap when collapsing a group of pages into a transparent huge page::
247 ``huge=``. It can have following values:
250     Attempt to allocate huge pages every time we need a new page;
253     Do not allocate huge pages;
256     Only allocate huge page if it will be fully within i_size.
260     Only allocate huge pages if requested with fadvise()/madvise();
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
277     For use in emergencies, to force the huge option off from
280     Force the huge option on for all - very useful for testing;
293 The number of anonymous transparent huge pages currently used by the
295 To identify what applications are using anonymous transparent huge pages,
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
309 monitor how successfully the system is providing huge pages for use.
312 	is incremented every time a huge page is successfully
317 	a range of pages to collapse into one huge page and has
318 	successfully allocated a new huge page to store the data.
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
331 	of pages that should be collapsed into one huge page but failed
335 	is incremented every time a file huge page is successfully
339 	is incremented if a file huge page is attempted to be allocated
343 	is incremented if a file huge page cannot be charged and instead
348 	is incremented every time a file huge page is mapped into
352 	is incremented every time a huge page is split into base
354 	reason is that a huge page is old and is being reclaimed.
358 	is incremented if kernel fails to split huge
362 	is incremented when a huge page is put onto split
363 	queue. This happens when a huge page is partially unmapped and
370 	munmap() on part of huge page. It doesn't split huge page, only
374 	is incremented every time a huge zero page used for thp is
376 	the huge zero page, only its allocation.
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.
389 	for the huge page.
391 As the system ages, allocating huge pages may be expensive as the
393 huge page for use. There are some counters in ``/proc/vmstat`` to help
398 	memory compaction so that a huge page is free for use.
402 	freed a huge page for use.
411 for huge pages.