Lines Matching refs:by

45 details - the "what does it do?" - by reading the code.  One hopes that the
46 descriptions below add value by provide the answer to "why does it do that?".
55 by Larry Woodman of Red Hat to address several scalability problems with page
69  (*) Those owned by ramfs.
76 unevictable, either by definition or by circumstance, in the future.
102      where they can be found by isolate_lru_page(), we would prevent their
112 lists and statistics originally proposed and posted by Christoph Lameter.
125 memory controller; see Documentation/cgroups/memory.txt] by extending the
152 address space flag is provided, and this can be manipulated by a filesystem
200 page_evictable() also checks for mlocked pages by testing an additional page
201 flag, PG_mlocked (as wrapped by PageMlocked()), which is set when a page is
249 posted by Nick Piggin in an RFC patch entitled "mm: mlocked pages off LRU".
250 Nick posted his patch as an alternative to a patch posted by Christoph Lameter
259 Nick resolved this by putting mlocked pages back on the lru list before
262 replaced by walking the reverse map to determine whether any VM_LOCKED VMAs
270 pages.  When such a page has been "noticed" by the memory management subsystem,
275 the LRU.  Such pages can be "noticed" by memory management in several places:
311 for each VMA in the range specified by the call.  In the case of mlockall(),
329 Also note that a page returned by get_user_pages() could be truncated or
338 mlock_vma_page() will call TestSetPageMlocked() for each page returned by
340 be mlocked by another task/VMA and we don't want to do extra work.  We
348 back the page - by calling putback_lru_page() - which will notice that the page
386 The munlock() and munlockall() system calls are handled by the same functions -
388 lock operation indicated by an argument.  So, these system calls are also
389 handled by mlock_fixup().  Again, if called for an already munlocked VMA,
406 For munlock(), populate_vma_page_range() unlocks individual pages by calling
410 the page might have already been unlocked by another task.  If the page was
413 the page is mapped by other VM_LOCKED VMAs.
444 can skip these pages by testing the page mapping under page lock.
448 page on failure - will be freed when the reference count held by the migration
460 unevictable LRU is enabled, the work of compaction is mostly handled by
476 Furthermore, any mmap() call or brk() call that expands the heap by a
499 When unmapping an mlocked region of memory, whether by an explicit call to
514 for the VMA's memory range and munlock_vma_page() each resident page mapped by
532 try_to_unmap() is always called, by either vmscan for reclaim or for page
558 the page is mapped by any VM_LOCKED VMA without actually attempting to unmap
567 undoes the pre-clearing of the page's PG_mlocked done by munlock_vma_page.