Lines Matching refs:pages

8 using huge pages for the backing of virtual memory with huge pages
40   working on the regular pages and their respective regular pmd/pte
44   regular pages should be gracefully allocated instead and mixed in
50   backed by regular pages should be relocated on hugepages
55   to avoid unmovable pages to fragment all the memory but such a tweak
108 to never try to defrag memory and simply fallback to regular pages
111 we use hugepages later instead of regular pages. This isn't always
139 You can also control how many pages khugepaged should scan at each
154 The khugepaged progress can be seen in the number of pages collapsed:
162 max_ptes_none specifies how many extra small pages (that are
164 of small pages into one large page.
173 max_ptes_swap specifies how many pages can be brought in from
174 swap when collapsing a group of pages into a transparent huge page.
180 collapsed, resulting fewer pages being collapsed into
199 The number of transparent huge pages currently used by the system is
201 identify what applications are using transparent huge pages, it is
207 monitor how successfully the system is providing huge pages for use.
214 	a range of pages to collapse into one huge page and has
218 	a huge page and instead falls back to using small pages.
221 	of pages that should be collapsed into one huge page but failed
225 	pages. This can happen for a variety of reasons but a common
234 	huge zero page and falls back to using small pages.
236 As the system ages, allocating huge pages may be expensive as the
260 	a huge page aligned range of pages.
265 for huge pages.
270 head or tail pages as usual (exactly as they would do on
278 split_huge_page() to avoid the head and tail pages to disappear from
287 In case you can't handle compound pages if they're returned by
372 page to the tail pages before clearing all PG_head/tail bits from the
375 and tail pages if running get_user_pages on an address backed by any
376 hugepage), requires the refcount to be accounted on the tail pages and
377 not only in the head pages, if we want to be able to run
384 hugetlbfs pages cannot be split so there wouldn't be requirement of
385 accounting the pins on the tail pages for hugetlbfs). If we wouldn't
386 account the gup refcounts on the tail pages during gup, we won't know