Lines Matching refs:huge
13 using huge pages for the backing of virtual memory with huge pages
22 the huge page size is 2M, although the actual numbers may vary
53 collapses sequences of basic pages into huge pages.
151 By default kernel tries to use huge zero page on read page fault to
152 anonymous mapping. It's possible to disable huge zero page by writing 0
214 swap when collapsing a group of pages into a transparent huge page::
235 ``huge=``. It can have following values:
238 Attempt to allocate huge pages every time we need a new page;
241 Do not allocate huge pages;
244 Only allocate huge page if it will be fully within i_size.
248 Only allocate huge pages if requested with fadvise()/madvise();
252 ``mount -o remount,huge= /mountpoint`` works fine after mount: remounting
253 ``huge=never`` will not attempt to break up huge pages at all, just stop more
265 For use in emergencies, to force the huge option off from
268 Force the huge option on for all - very useful for testing;
281 The number of anonymous transparent huge pages currently used by the
283 To identify what applications are using anonymous transparent huge pages,
287 The number of file transparent huge pages mapped to userspace is available
289 To identify what applications are mapping file transparent huge pages, it
297 monitor how successfully the system is providing huge pages for use.
300 is incremented every time a huge page is successfully
306 a range of pages to collapse into one huge page and has
307 successfully allocated a new huge page to store the data.
311 a huge page and instead falls back to using small pages.
315 of pages that should be collapsed into one huge page but failed
319 is incremented every time a file huge page is successfully
323 is incremented every time a file huge page is mapped into
327 is incremented every time a huge page is split into base
329 reason is that a huge page is old and is being reclaimed.
333 is incremented if kernel fails to split huge
337 is incremented when a huge page is put onto split
338 queue. This happens when a huge page is partially unmapped and
345 munmap() on part of huge page. It doesn't split huge page, only
349 is incremented every time a huge zero page is
352 every map of the huge zero page, only its allocation.
356 huge zero page and falls back to using small pages.
359 is incremented every time a huge page is swapout in one
363 is incremented if a huge page has to be split before swapout.
365 for the huge page.
367 As the system ages, allocating huge pages may be expensive as the
369 huge page for use. There are some counters in ``/proc/vmstat`` to help
374 memory compaction so that a huge page is free for use.
378 freed a huge page for use.
387 is copying a lot of data to satisfy the huge page allocation.
397 a huge page aligned range of pages.
402 for huge pages.