Lines Matching refs:huge

8 using huge pages for the backing of virtual memory with huge pages
119 By default kernel tries to use huge zero page on read page fault.
120 It's possible to disable huge zero page by writing 0 or enable it
189 The number of transparent huge pages currently used by the system is
191 identify what applications are using transparent huge pages, it is
197 monitor how successfully the system is providing huge pages for use.
199 thp_fault_alloc is incremented every time a huge page is successfully
204 	a range of pages to collapse into one huge page and has
205 	successfully allocated a new huge page to store the data.
208 	a huge page and instead falls back to using small pages.
211 	of pages that should be collapsed into one huge page but failed
214 thp_split is incremented every time a huge page is split into base
216 	reason is that a huge page is old and is being reclaimed.
218 thp_zero_page_alloc is incremented every time a huge zero page is
221 	every map of the huge zero page, only its allocation.
224 	huge zero page and falls back to using small pages.
226 As the system ages, allocating huge pages may be expensive as the
228 huge page for use. There are some counters in /proc/vmstat to help
232 	memory compaction so that a huge page is free for use.
235 	freed a huge page for use.
242 	is copying a lot of data to satisfy the huge page allocation.
250 	a huge page aligned range of pages.
255 for huge pages.
263 is complete, so they won't ever notice the fact the page is huge. But
304 Code walking pagetables but unware about huge pmds can simply call
337 To make pagetable walks huge pmd aware, all you need to do is to call
339 mmap_sem in read (or write) mode to be sure an huge pmd cannot be
345 page_table_lock will prevent the huge pmd to be converted into a
355 huge anymore. If pmd_trans_splitting returns false, you can proceed to
356 process the huge pmd and the hugepage natively. Once finished you can
363 page structures. It can do that easily for refcounts taken by huge pmd