Lines Matching full:list
27 The Unevictable LRU facility adds an additional LRU list to track unevictable
41 The unevictable list addresses the following classes of unevictable pages:
55 The Unevictable LRU Folio List
58 The Unevictable LRU folio list is a lie. It was never an LRU-ordered
59 list, but a companion to the LRU-ordered anonymous and file, active and
60 inactive folio lists; and now it is not even a folio list. But following
62 imagine it as a fifth LRU folio list.
64 The Unevictable LRU infrastructure consists of an additional, per-node, LRU list
65 called the "unevictable" list and an associated folio flag, PG_unevictable, to
66 indicate that the folio is being managed on the unevictable list.
69 PG_active flag in that it indicates on which LRU list a folio resides when
73 on an additional LRU list for a few reasons:
84 maintain folios elsewhere than on an LRU-like list, where they can be
87 The unevictable list does not differentiate between file-backed and
91 The unevictable list benefits from the "arrayification" of the per-node LRU
103 list as a result of the "arrayification" of the per-node LRU lists (one per
105 and from the unevictable list.
108 not attempt to reclaim pages on the unevictable list. This has a couple of
111 (1) Because the pages are "hidden" from reclaim on the unevictable list, the
171 list. Instead, vmscan will do this if and when it encounters the folios during
175 the pages in the region and "rescue" them from the unevictable list if no other
177 the pages are also "rescued" from the unevictable list in the process of
189 list at mlock() or mmap() time, vmscan will not encounter the folios until they
191 from the unevictable list. However, there may be situations where we decide,
196 unevictable list for the memory cgroup and node being scanned.
202 or try_to_unmap(). The folio is culled to the unevictable list when it
206 the LRU list using folio_putback_lru() - the inverse operation to
210 of a folio before placing it on the unevictable list.
216 The unevictable folio list is also useful for mlock(), in addition to ramfs and
229 In Nick's patch, he used one of the struct page LRU list link fields as a count
232 of the pages on an LRU list, and thus mlocked pages were not migratable as
233 isolate_lru_page() could not detect them, and the LRU list link field was not
236 Nick resolved this by putting mlocked pages back on the LRU list before
245 idea of keeping mlock_count in Unevictable LRU list link field was revived and
247 the "Unevictable LRU list" cannot be a linked list of pages now; but there was
248 no use for that linked list anyway - though its size is maintained for meminfo.
259 A PG_mlocked page will be placed on the unevictable list when it is added to
275 mlocked pages become unlocked and rescued from the unevictable list when:
437 A transparent huge page is represented by a single entry on an LRU list.
533 i.e. !page_evictable(page) pages - diverting those to the unevictable list.
536 set - otherwise they would be on the unevictable list and shrink_active_list()
553 and node unevictable list.
558 to correct them. Such pages are culled to the unevictable list when released