Lines Matching refs:LRU

2 Unevictable LRU Infrastructure
11 This document describes the Linux memory manager's "Unevictable LRU"
24 The Unevictable LRU
27 The Unevictable LRU facility adds an additional LRU list to track unevictable
36 will spend a lot of time scanning the LRU lists looking for the small fraction
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
62 imagine it as a fifth LRU folio list.
64 The Unevictable LRU infrastructure consists of an additional, per-node, LRU list
69 PG_active flag in that it indicates on which LRU list a folio resides when
72 The Unevictable LRU infrastructure maintains unevictable folios as if they were
73 on an additional LRU list for a few reasons:
82      can only migrate folios that it can successfully isolate from the LRU
84      maintain folios elsewhere than on an LRU-like list, where they can be
91 The unevictable list benefits from the "arrayification" of the per-node LRU
98 The unevictable LRU facility interacts with the memory control group [aka
103 list as a result of the "arrayification" of the per-node LRU lists (one per
193 active/inactive LRU lists for vmscan to deal with.  vmscan checks for such
206 the LRU list using folio_putback_lru() - the inverse operation to
225 posted by Nick Piggin in an RFC patch entitled "mm: mlocked pages off LRU".
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 folio_isolate_lru() 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
238 Nick's patch was integrated with the Unevictable LRU work, the count was
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
260 the LRU.  Such pages can be "noticed" by memory management in several places:
318 judgments, since this page is held exclusively and known not to be on LRU yet.
323 and moves the page to unevictable state ("the unevictable LRU", but with
324 mlock_count in place of LRU threading).  Or if the page was already PG_lru
327 But in practice that may not work ideally: the page may not yet be on an LRU, or
328 it may have been temporarily isolated from LRU.  In such cases the mlock_count
330 returns the page to "LRU".  Races prohibit mlock_count from being set to 1 then:
333 an evictable LRU, then perhaps be mlocked again later if vmscan finds it in a
354    unevictable and are not managed on the LRU lists.  __mm_populate() includes
385 to the inactive LRU.
388 "the unevictable LRU", or it may have been temporarily isolated from it.  In
390 that the folio will be rescued to an evictable LRU, then perhaps be mlocked
397 A page that is being migrated has been isolated from the LRU lists and is held
419 To complete page migration, we place the old and new pages back onto the LRU
437 A transparent huge page is represented by a single entry on an LRU list.
447 We handle this by keeping PTE-mlocked huge pages on evictable LRU lists:
452 to the unevictable LRU and the rest can be reclaimed.
497 to the inactive LRU.
500 "the unevictable LRU", or it may have been temporarily isolated from it.  In
502 that the folio will be rescued to an evictable LRU, then perhaps be mlocked
535 active/inactive LRU lists.  Note that these pages do not have PG_unevictable
539 Some examples of these unevictable pages on the LRU lists are:
541  (1) ramfs pages that have been placed on the LRU lists when first allocated.