Documentation/vm/unevictable-lru.rst

14 infrastructure and the use of this to manage several types of "unevictable"
29 The Unevictable LRU facility adds an additional LRU list to track unevictable
43 The unevictable list addresses the following classes of unevictable pages:
52 unevictable, either by definition or by circumstance, in the future.
59 called the "unevictable" list and an associated page flag, PG_unevictable, to
60 indicate that the page is being managed on the unevictable list.
66 The Unevictable LRU infrastructure maintains unevictable pages on an additional
69  (1) We get to "treat unevictable pages just like we treat other pages in the
74  (2) We want to be able to migrate unevictable pages between nodes for memory
79      migration, unless we reworked migration code to find the unevictable pages
83 The unevictable list does not differentiate between file-backed and anonymous,
87 The unevictable list benefits from the "arrayification" of the per-zone LRU
90 The unevictable list does not use the LRU pagevec mechanism. Rather,
91 unevictable pages are placed directly on the page's zone's unevictable list
93 the unevictable list when one task has the page isolated from the LRU and other
100 The unevictable LRU facility interacts with the memory control group [aka
104 The memory controller data structure automatically gets a per-zone unevictable
107 and from the unevictable list.
110 not attempt to reclaim pages on the unevictable list.  This has a couple of
113  (1) Because the pages are "hidden" from reclaim on the unevictable list, the
118      are unevictable, the evictable portion of the working set of the tasks in
135 	Mark the address space as being completely unevictable.
144 	unevictable.
158      amount of unevictable memory marked by i915 driver is roughly the bounded
167 :ref:`Marking address spaces unevictable <mark_addr_space_unevict>`]
173 any special effort to push any pages in the SHM_LOCK'd area to the unevictable
178 the pages in the region and "rescue" them from the unevictable list if no other
179 condition is keeping them unevictable.  If an unevictable region is destroyed,
180 the pages are also "rescued" from the unevictable list in the process of
191 If unevictable pages are culled in the fault path, or moved to the unevictable
194 from the unevictable list.  However, there may be situations where we decide,
195 for the sake of expediency, to leave a unevictable page on one of the regular
199 unevictable list for the zone being scanned.
207 To "cull" an unevictable page, vmscan simply puts the page back on the LRU list
209 dropping the page lock.  Because the condition which makes the page unevictable
211 unevictable state of a page that it places on the unevictable list.  If the
212 page has become unevictable, putback_lru_page() removes it from the list and
214 event and movement of pages onto the unevictable list should be rare, these
222 The unevictable page list is also useful for mlock(), in addition to ramfs and
251 mlocked pages - pages mapped into a VM_LOCKED VMA - are a class of unevictable
256 A PG_mlocked page will be placed on the unevictable list when it is added to
276 mlocked pages become unlocked and rescued from the unevictable list when:
331 is now mlocked and divert the page to the zone's unevictable list.  If
349    prior behavior of mlock() - before the unevictable/mlock changes -
355    are inherently unevictable and are not managed on the LRU lists.
419 of mlocked pages and other unevictable pages.  This involves simply moving the
432 process is released.  To ensure that we don't strand pages on the unevictable
440 The unevictable LRU can be scanned for compactable regions and the default
443 unevictable LRU is enabled, the work of compaction is mostly handled by
451 Therefore, we can only make unevictable an entire compound page, not
465 to unevictable LRU and the rest can be reclaimed.
482 in the newly mapped memory being mlocked.  Before the unevictable/mlock
486 To mlock a range of memory under the unevictable/mlock infrastructure, the
506 Before the unevictable/mlock changes, mlocking did not mark the pages in any
509 To munlock a range of memory under the unevictable/mlock infrastructure, the
532 in section "vmscan's handling of unevictable pages".  To handle this situation,
545 and return SWAP_MLOCK to indicate that the page is unevictable: and the scan
565 page.  For this purpose, the unevictable/mlock infrastructure
586 shrink_active_list() culls any obviously unevictable pages - i.e.
587 !page_evictable(page) - diverting these to the unevictable list.
588 However, shrink_active_list() only sees unevictable pages that made it onto the
590 set - otherwise they would be on the unevictable list and shrink_active_list
593 Some examples of these unevictable pages on the LRU lists are:
603      unevictable list in mlock_vma_page().
605 shrink_inactive_list() also diverts any unevictable pages that it finds on the
606 inactive lists to the appropriate zone's unevictable list.
614 shrink_page_list() again culls obviously unevictable pages that it could
617 try_to_unmap().  shrink_page_list() will divert them to the unevictable list