1============================== 2Unevictable LRU Infrastructure 3============================== 4 5.. contents:: :local: 6 7 8Introduction 9============ 10 11This document describes the Linux memory manager's "Unevictable LRU" 12infrastructure and the use of this to manage several types of "unevictable" 13pages. 14 15The document attempts to provide the overall rationale behind this mechanism 16and the rationale for some of the design decisions that drove the 17implementation. The latter design rationale is discussed in the context of an 18implementation description. Admittedly, one can obtain the implementation 19details - the "what does it do?" - by reading the code. One hopes that the 20descriptions below add value by provide the answer to "why does it do that?". 21 22 23 24The Unevictable LRU 25=================== 26 27The Unevictable LRU facility adds an additional LRU list to track unevictable 28pages and to hide these pages from vmscan. This mechanism is based on a patch 29by Larry Woodman of Red Hat to address several scalability problems with page 30reclaim in Linux. The problems have been observed at customer sites on large 31memory x86_64 systems. 32 33To illustrate this with an example, a non-NUMA x86_64 platform with 128GB of 34main memory will have over 32 million 4k pages in a single node. When a large 35fraction of these pages are not evictable for any reason [see below], vmscan 36will spend a lot of time scanning the LRU lists looking for the small fraction 37of pages that are evictable. This can result in a situation where all CPUs are 38spending 100% of their time in vmscan for hours or days on end, with the system 39completely unresponsive. 40 41The unevictable list addresses the following classes of unevictable pages: 42 43 * Those owned by ramfs. 44 45 * Those mapped into SHM_LOCK'd shared memory regions. 46 47 * Those mapped into VM_LOCKED [mlock()ed] VMAs. 48 49The infrastructure may also be able to handle other conditions that make pages 50unevictable, either by definition or by circumstance, in the future. 51 52 53The Unevictable LRU Page List 54----------------------------- 55 56The Unevictable LRU page list is a lie. It was never an LRU-ordered list, but a 57companion to the LRU-ordered anonymous and file, active and inactive page lists; 58and now it is not even a page list. But following familiar convention, here in 59this document and in the source, we often imagine it as a fifth LRU page list. 60 61The Unevictable LRU infrastructure consists of an additional, per-node, LRU list 62called the "unevictable" list and an associated page flag, PG_unevictable, to 63indicate that the page is being managed on the unevictable list. 64 65The PG_unevictable flag is analogous to, and mutually exclusive with, the 66PG_active flag in that it indicates on which LRU list a page resides when 67PG_lru is set. 68 69The Unevictable LRU infrastructure maintains unevictable pages as if they were 70on an additional LRU list for a few reasons: 71 72 (1) We get to "treat unevictable pages just like we treat other pages in the 73 system - which means we get to use the same code to manipulate them, the 74 same code to isolate them (for migrate, etc.), the same code to keep track 75 of the statistics, etc..." [Rik van Riel] 76 77 (2) We want to be able to migrate unevictable pages between nodes for memory 78 defragmentation, workload management and memory hotplug. The Linux kernel 79 can only migrate pages that it can successfully isolate from the LRU 80 lists (or "Movable" pages: outside of consideration here). If we were to 81 maintain pages elsewhere than on an LRU-like list, where they can be 82 detected by isolate_lru_page(), we would prevent their migration. 83 84The unevictable list does not differentiate between file-backed and anonymous, 85swap-backed pages. This differentiation is only important while the pages are, 86in fact, evictable. 87 88The unevictable list benefits from the "arrayification" of the per-node LRU 89lists and statistics originally proposed and posted by Christoph Lameter. 90 91 92Memory Control Group Interaction 93-------------------------------- 94 95The unevictable LRU facility interacts with the memory control group [aka 96memory controller; see Documentation/admin-guide/cgroup-v1/memory.rst] by 97extending the lru_list enum. 98 99The memory controller data structure automatically gets a per-node unevictable 100list as a result of the "arrayification" of the per-node LRU lists (one per 101lru_list enum element). The memory controller tracks the movement of pages to 102and from the unevictable list. 103 104When a memory control group comes under memory pressure, the controller will 105not attempt to reclaim pages on the unevictable list. This has a couple of 106effects: 107 108 (1) Because the pages are "hidden" from reclaim on the unevictable list, the 109 reclaim process can be more efficient, dealing only with pages that have a 110 chance of being reclaimed. 111 112 (2) On the other hand, if too many of the pages charged to the control group 113 are unevictable, the evictable portion of the working set of the tasks in 114 the control group may not fit into the available memory. This can cause 115 the control group to thrash or to OOM-kill tasks. 116 117 118.. _mark_addr_space_unevict: 119 120Marking Address Spaces Unevictable 121---------------------------------- 122 123For facilities such as ramfs none of the pages attached to the address space 124may be evicted. To prevent eviction of any such pages, the AS_UNEVICTABLE 125address space flag is provided, and this can be manipulated by a filesystem 126using a number of wrapper functions: 127 128 * ``void mapping_set_unevictable(struct address_space *mapping);`` 129 130 Mark the address space as being completely unevictable. 131 132 * ``void mapping_clear_unevictable(struct address_space *mapping);`` 133 134 Mark the address space as being evictable. 135 136 * ``int mapping_unevictable(struct address_space *mapping);`` 137 138 Query the address space, and return true if it is completely 139 unevictable. 140 141These are currently used in three places in the kernel: 142 143 (1) By ramfs to mark the address spaces of its inodes when they are created, 144 and this mark remains for the life of the inode. 145 146 (2) By SYSV SHM to mark SHM_LOCK'd address spaces until SHM_UNLOCK is called. 147 Note that SHM_LOCK is not required to page in the locked pages if they're 148 swapped out; the application must touch the pages manually if it wants to 149 ensure they're in memory. 150 151 (3) By the i915 driver to mark pinned address space until it's unpinned. The 152 amount of unevictable memory marked by i915 driver is roughly the bounded 153 object size in debugfs/dri/0/i915_gem_objects. 154 155 156Detecting Unevictable Pages 157--------------------------- 158 159The function page_evictable() in mm/internal.h determines whether a page is 160evictable or not using the query function outlined above [see section 161:ref:`Marking address spaces unevictable <mark_addr_space_unevict>`] 162to check the AS_UNEVICTABLE flag. 163 164For address spaces that are so marked after being populated (as SHM regions 165might be), the lock action (e.g. SHM_LOCK) can be lazy, and need not populate 166the page tables for the region as does, for example, mlock(), nor need it make 167any special effort to push any pages in the SHM_LOCK'd area to the unevictable 168list. Instead, vmscan will do this if and when it encounters the pages during 169a reclamation scan. 170 171On an unlock action (such as SHM_UNLOCK), the unlocker (e.g. shmctl()) must scan 172the pages in the region and "rescue" them from the unevictable list if no other 173condition is keeping them unevictable. If an unevictable region is destroyed, 174the pages are also "rescued" from the unevictable list in the process of 175freeing them. 176 177page_evictable() also checks for mlocked pages by testing an additional page 178flag, PG_mlocked (as wrapped by PageMlocked()), which is set when a page is 179faulted into a VM_LOCKED VMA, or found in a VMA being VM_LOCKED. 180 181 182Vmscan's Handling of Unevictable Pages 183-------------------------------------- 184 185If unevictable pages are culled in the fault path, or moved to the unevictable 186list at mlock() or mmap() time, vmscan will not encounter the pages until they 187have become evictable again (via munlock() for example) and have been "rescued" 188from the unevictable list. However, there may be situations where we decide, 189for the sake of expediency, to leave an unevictable page on one of the regular 190active/inactive LRU lists for vmscan to deal with. vmscan checks for such 191pages in all of the shrink_{active|inactive|page}_list() functions and will 192"cull" such pages that it encounters: that is, it diverts those pages to the 193unevictable list for the memory cgroup and node being scanned. 194 195There may be situations where a page is mapped into a VM_LOCKED VMA, but the 196page is not marked as PG_mlocked. Such pages will make it all the way to 197shrink_active_list() or shrink_page_list() where they will be detected when 198vmscan walks the reverse map in folio_referenced() or try_to_unmap(). The page 199is culled to the unevictable list when it is released by the shrinker. 200 201To "cull" an unevictable page, vmscan simply puts the page back on the LRU list 202using putback_lru_page() - the inverse operation to isolate_lru_page() - after 203dropping the page lock. Because the condition which makes the page unevictable 204may change once the page is unlocked, __pagevec_lru_add_fn() will recheck the 205unevictable state of a page before placing it on the unevictable list. 206 207 208MLOCKED Pages 209============= 210 211The unevictable page list is also useful for mlock(), in addition to ramfs and 212SYSV SHM. Note that mlock() is only available in CONFIG_MMU=y situations; in 213NOMMU situations, all mappings are effectively mlocked. 214 215 216History 217------- 218 219The "Unevictable mlocked Pages" infrastructure is based on work originally 220posted by Nick Piggin in an RFC patch entitled "mm: mlocked pages off LRU". 221Nick posted his patch as an alternative to a patch posted by Christoph Lameter 222to achieve the same objective: hiding mlocked pages from vmscan. 223 224In Nick's patch, he used one of the struct page LRU list link fields as a count 225of VM_LOCKED VMAs that map the page (Rik van Riel had the same idea three years 226earlier). But this use of the link field for a count prevented the management 227of the pages on an LRU list, and thus mlocked pages were not migratable as 228isolate_lru_page() could not detect them, and the LRU list link field was not 229available to the migration subsystem. 230 231Nick resolved this by putting mlocked pages back on the LRU list before 232attempting to isolate them, thus abandoning the count of VM_LOCKED VMAs. When 233Nick's patch was integrated with the Unevictable LRU work, the count was 234replaced by walking the reverse map when munlocking, to determine whether any 235other VM_LOCKED VMAs still mapped the page. 236 237However, walking the reverse map for each page when munlocking was ugly and 238inefficient, and could lead to catastrophic contention on a file's rmap lock, 239when many processes which had it mlocked were trying to exit. In 5.18, the 240idea of keeping mlock_count in Unevictable LRU list link field was revived and 241put to work, without preventing the migration of mlocked pages. This is why 242the "Unevictable LRU list" cannot be a linked list of pages now; but there was 243no use for that linked list anyway - though its size is maintained for meminfo. 244 245 246Basic Management 247---------------- 248 249mlocked pages - pages mapped into a VM_LOCKED VMA - are a class of unevictable 250pages. When such a page has been "noticed" by the memory management subsystem, 251the page is marked with the PG_mlocked flag. This can be manipulated using the 252PageMlocked() functions. 253 254A PG_mlocked page will be placed on the unevictable list when it is added to 255the LRU. Such pages can be "noticed" by memory management in several places: 256 257 (1) in the mlock()/mlock2()/mlockall() system call handlers; 258 259 (2) in the mmap() system call handler when mmapping a region with the 260 MAP_LOCKED flag; 261 262 (3) mmapping a region in a task that has called mlockall() with the MCL_FUTURE 263 flag; 264 265 (4) in the fault path and when a VM_LOCKED stack segment is expanded; or 266 267 (5) as mentioned above, in vmscan:shrink_page_list() when attempting to 268 reclaim a page in a VM_LOCKED VMA by folio_referenced() or try_to_unmap(). 269 270mlocked pages become unlocked and rescued from the unevictable list when: 271 272 (1) mapped in a range unlocked via the munlock()/munlockall() system calls; 273 274 (2) munmap()'d out of the last VM_LOCKED VMA that maps the page, including 275 unmapping at task exit; 276 277 (3) when the page is truncated from the last VM_LOCKED VMA of an mmapped file; 278 or 279 280 (4) before a page is COW'd in a VM_LOCKED VMA. 281 282 283mlock()/mlock2()/mlockall() System Call Handling 284------------------------------------------------ 285 286mlock(), mlock2() and mlockall() system call handlers proceed to mlock_fixup() 287for each VMA in the range specified by the call. In the case of mlockall(), 288this is the entire active address space of the task. Note that mlock_fixup() 289is used for both mlocking and munlocking a range of memory. A call to mlock() 290an already VM_LOCKED VMA, or to munlock() a VMA that is not VM_LOCKED, is 291treated as a no-op and mlock_fixup() simply returns. 292 293If the VMA passes some filtering as described in "Filtering Special VMAs" 294below, mlock_fixup() will attempt to merge the VMA with its neighbors or split 295off a subset of the VMA if the range does not cover the entire VMA. Any pages 296already present in the VMA are then marked as mlocked by mlock_page() via 297mlock_pte_range() via walk_page_range() via mlock_vma_pages_range(). 298 299Before returning from the system call, do_mlock() or mlockall() will call 300__mm_populate() to fault in the remaining pages via get_user_pages() and to 301mark those pages as mlocked as they are faulted. 302 303Note that the VMA being mlocked might be mapped with PROT_NONE. In this case, 304get_user_pages() will be unable to fault in the pages. That's okay. If pages 305do end up getting faulted into this VM_LOCKED VMA, they will be handled in the 306fault path - which is also how mlock2()'s MLOCK_ONFAULT areas are handled. 307 308For each PTE (or PMD) being faulted into a VMA, the page add rmap function 309calls mlock_vma_page(), which calls mlock_page() when the VMA is VM_LOCKED 310(unless it is a PTE mapping of a part of a transparent huge page). Or when 311it is a newly allocated anonymous page, lru_cache_add_inactive_or_unevictable() 312calls mlock_new_page() instead: similar to mlock_page(), but can make better 313judgments, since this page is held exclusively and known not to be on LRU yet. 314 315mlock_page() sets PageMlocked immediately, then places the page on the CPU's 316mlock pagevec, to batch up the rest of the work to be done under lru_lock by 317__mlock_page(). __mlock_page() sets PageUnevictable, initializes mlock_count 318and moves the page to unevictable state ("the unevictable LRU", but with 319mlock_count in place of LRU threading). Or if the page was already PageLRU 320and PageUnevictable and PageMlocked, it simply increments the mlock_count. 321 322But in practice that may not work ideally: the page may not yet be on an LRU, or 323it may have been temporarily isolated from LRU. In such cases the mlock_count 324field cannot be touched, but will be set to 0 later when __pagevec_lru_add_fn() 325returns the page to "LRU". Races prohibit mlock_count from being set to 1 then: 326rather than risk stranding a page indefinitely as unevictable, always err with 327mlock_count on the low side, so that when munlocked the page will be rescued to 328an evictable LRU, then perhaps be mlocked again later if vmscan finds it in a 329VM_LOCKED VMA. 330 331 332Filtering Special VMAs 333---------------------- 334 335mlock_fixup() filters several classes of "special" VMAs: 336 3371) VMAs with VM_IO or VM_PFNMAP set are skipped entirely. The pages behind 338 these mappings are inherently pinned, so we don't need to mark them as 339 mlocked. In any case, most of the pages have no struct page in which to so 340 mark the page. Because of this, get_user_pages() will fail for these VMAs, 341 so there is no sense in attempting to visit them. 342 3432) VMAs mapping hugetlbfs page are already effectively pinned into memory. We 344 neither need nor want to mlock() these pages. But __mm_populate() includes 345 hugetlbfs ranges, allocating the huge pages and populating the PTEs. 346 3473) VMAs with VM_DONTEXPAND are generally userspace mappings of kernel pages, 348 such as the VDSO page, relay channel pages, etc. These pages are inherently 349 unevictable and are not managed on the LRU lists. __mm_populate() includes 350 these ranges, populating the PTEs if not already populated. 351 3524) VMAs with VM_MIXEDMAP set are not marked VM_LOCKED, but __mm_populate() 353 includes these ranges, populating the PTEs if not already populated. 354 355Note that for all of these special VMAs, mlock_fixup() does not set the 356VM_LOCKED flag. Therefore, we won't have to deal with them later during 357munlock(), munmap() or task exit. Neither does mlock_fixup() account these 358VMAs against the task's "locked_vm". 359 360 361munlock()/munlockall() System Call Handling 362------------------------------------------- 363 364The munlock() and munlockall() system calls are handled by the same 365mlock_fixup() function as mlock(), mlock2() and mlockall() system calls are. 366If called to munlock an already munlocked VMA, mlock_fixup() simply returns. 367Because of the VMA filtering discussed above, VM_LOCKED will not be set in 368any "special" VMAs. So, those VMAs will be ignored for munlock. 369 370If the VMA is VM_LOCKED, mlock_fixup() again attempts to merge or split off the 371specified range. All pages in the VMA are then munlocked by munlock_page() via 372mlock_pte_range() via walk_page_range() via mlock_vma_pages_range() - the same 373function used when mlocking a VMA range, with new flags for the VMA indicating 374that it is munlock() being performed. 375 376munlock_page() uses the mlock pagevec to batch up work to be done under 377lru_lock by __munlock_page(). __munlock_page() decrements the page's 378mlock_count, and when that reaches 0 it clears PageMlocked and clears 379PageUnevictable, moving the page from unevictable state to inactive LRU. 380 381But in practice that may not work ideally: the page may not yet have reached 382"the unevictable LRU", or it may have been temporarily isolated from it. In 383those cases its mlock_count field is unusable and must be assumed to be 0: so 384that the page will be rescued to an evictable LRU, then perhaps be mlocked 385again later if vmscan finds it in a VM_LOCKED VMA. 386 387 388Migrating MLOCKED Pages 389----------------------- 390 391A page that is being migrated has been isolated from the LRU lists and is held 392locked across unmapping of the page, updating the page's address space entry 393and copying the contents and state, until the page table entry has been 394replaced with an entry that refers to the new page. Linux supports migration 395of mlocked pages and other unevictable pages. PG_mlocked is cleared from the 396the old page when it is unmapped from the last VM_LOCKED VMA, and set when the 397new page is mapped in place of migration entry in a VM_LOCKED VMA. If the page 398was unevictable because mlocked, PG_unevictable follows PG_mlocked; but if the 399page was unevictable for other reasons, PG_unevictable is copied explicitly. 400 401Note that page migration can race with mlocking or munlocking of the same page. 402There is mostly no problem since page migration requires unmapping all PTEs of 403the old page (including munlock where VM_LOCKED), then mapping in the new page 404(including mlock where VM_LOCKED). The page table locks provide sufficient 405synchronization. 406 407However, since mlock_vma_pages_range() starts by setting VM_LOCKED on a VMA, 408before mlocking any pages already present, if one of those pages were migrated 409before mlock_pte_range() reached it, it would get counted twice in mlock_count. 410To prevent that, mlock_vma_pages_range() temporarily marks the VMA as VM_IO, 411so that mlock_vma_page() will skip it. 412 413To complete page migration, we place the old and new pages back onto the LRU 414afterwards. The "unneeded" page - old page on success, new page on failure - 415is freed when the reference count held by the migration process is released. 416 417 418Compacting MLOCKED Pages 419------------------------ 420 421The memory map can be scanned for compactable regions and the default behavior 422is to let unevictable pages be moved. /proc/sys/vm/compact_unevictable_allowed 423controls this behavior (see Documentation/admin-guide/sysctl/vm.rst). The work 424of compaction is mostly handled by the page migration code and the same work 425flow as described in Migrating MLOCKED Pages will apply. 426 427 428MLOCKING Transparent Huge Pages 429------------------------------- 430 431A transparent huge page is represented by a single entry on an LRU list. 432Therefore, we can only make unevictable an entire compound page, not 433individual subpages. 434 435If a user tries to mlock() part of a huge page, and no user mlock()s the 436whole of the huge page, we want the rest of the page to be reclaimable. 437 438We cannot just split the page on partial mlock() as split_huge_page() can 439fail and a new intermittent failure mode for the syscall is undesirable. 440 441We handle this by keeping PTE-mlocked huge pages on evictable LRU lists: 442the PMD on the border of a VM_LOCKED VMA will be split into a PTE table. 443 444This way the huge page is accessible for vmscan. Under memory pressure the 445page will be split, subpages which belong to VM_LOCKED VMAs will be moved 446to the unevictable LRU and the rest can be reclaimed. 447 448/proc/meminfo's Unevictable and Mlocked amounts do not include those parts 449of a transparent huge page which are mapped only by PTEs in VM_LOCKED VMAs. 450 451 452mmap(MAP_LOCKED) System Call Handling 453------------------------------------- 454 455In addition to the mlock(), mlock2() and mlockall() system calls, an application 456can request that a region of memory be mlocked by supplying the MAP_LOCKED flag 457to the mmap() call. There is one important and subtle difference here, though. 458mmap() + mlock() will fail if the range cannot be faulted in (e.g. because 459mm_populate fails) and returns with ENOMEM while mmap(MAP_LOCKED) will not fail. 460The mmaped area will still have properties of the locked area - pages will not 461get swapped out - but major page faults to fault memory in might still happen. 462 463Furthermore, any mmap() call or brk() call that expands the heap by a task 464that has previously called mlockall() with the MCL_FUTURE flag will result 465in the newly mapped memory being mlocked. Before the unevictable/mlock 466changes, the kernel simply called make_pages_present() to allocate pages 467and populate the page table. 468 469To mlock a range of memory under the unevictable/mlock infrastructure, 470the mmap() handler and task address space expansion functions call 471populate_vma_page_range() specifying the vma and the address range to mlock. 472 473 474munmap()/exit()/exec() System Call Handling 475------------------------------------------- 476 477When unmapping an mlocked region of memory, whether by an explicit call to 478munmap() or via an internal unmap from exit() or exec() processing, we must 479munlock the pages if we're removing the last VM_LOCKED VMA that maps the pages. 480Before the unevictable/mlock changes, mlocking did not mark the pages in any 481way, so unmapping them required no processing. 482 483For each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls 484munlock_vma_page(), which calls munlock_page() when the VMA is VM_LOCKED 485(unless it was a PTE mapping of a part of a transparent huge page). 486 487munlock_page() uses the mlock pagevec to batch up work to be done under 488lru_lock by __munlock_page(). __munlock_page() decrements the page's 489mlock_count, and when that reaches 0 it clears PageMlocked and clears 490PageUnevictable, moving the page from unevictable state to inactive LRU. 491 492But in practice that may not work ideally: the page may not yet have reached 493"the unevictable LRU", or it may have been temporarily isolated from it. In 494those cases its mlock_count field is unusable and must be assumed to be 0: so 495that the page will be rescued to an evictable LRU, then perhaps be mlocked 496again later if vmscan finds it in a VM_LOCKED VMA. 497 498 499Truncating MLOCKED Pages 500------------------------ 501 502File truncation or hole punching forcibly unmaps the deleted pages from 503userspace; truncation even unmaps and deletes any private anonymous pages 504which had been Copied-On-Write from the file pages now being truncated. 505 506Mlocked pages can be munlocked and deleted in this way: like with munmap(), 507for each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls 508munlock_vma_page(), which calls munlock_page() when the VMA is VM_LOCKED 509(unless it was a PTE mapping of a part of a transparent huge page). 510 511However, if there is a racing munlock(), since mlock_vma_pages_range() starts 512munlocking by clearing VM_LOCKED from a VMA, before munlocking all the pages 513present, if one of those pages were unmapped by truncation or hole punch before 514mlock_pte_range() reached it, it would not be recognized as mlocked by this VMA, 515and would not be counted out of mlock_count. In this rare case, a page may 516still appear as PageMlocked after it has been fully unmapped: and it is left to 517release_pages() (or __page_cache_release()) to clear it and update statistics 518before freeing (this event is counted in /proc/vmstat unevictable_pgs_cleared, 519which is usually 0). 520 521 522Page Reclaim in shrink_*_list() 523------------------------------- 524 525vmscan's shrink_active_list() culls any obviously unevictable pages - 526i.e. !page_evictable(page) pages - diverting those to the unevictable list. 527However, shrink_active_list() only sees unevictable pages that made it onto the 528active/inactive LRU lists. Note that these pages do not have PageUnevictable 529set - otherwise they would be on the unevictable list and shrink_active_list() 530would never see them. 531 532Some examples of these unevictable pages on the LRU lists are: 533 534 (1) ramfs pages that have been placed on the LRU lists when first allocated. 535 536 (2) SHM_LOCK'd shared memory pages. shmctl(SHM_LOCK) does not attempt to 537 allocate or fault in the pages in the shared memory region. This happens 538 when an application accesses the page the first time after SHM_LOCK'ing 539 the segment. 540 541 (3) pages still mapped into VM_LOCKED VMAs, which should be marked mlocked, 542 but events left mlock_count too low, so they were munlocked too early. 543 544vmscan's shrink_inactive_list() and shrink_page_list() also divert obviously 545unevictable pages found on the inactive lists to the appropriate memory cgroup 546and node unevictable list. 547 548rmap's folio_referenced_one(), called via vmscan's shrink_active_list() or 549shrink_page_list(), and rmap's try_to_unmap_one() called via shrink_page_list(), 550check for (3) pages still mapped into VM_LOCKED VMAs, and call mlock_vma_page() 551to correct them. Such pages are culled to the unevictable list when released 552by the shrinker. 553