Lines Matching full:page
4 Page migration
7 Page migration allows moving the physical location of pages between
15 The main intent of page migration is to reduce the latency of memory accesses
19 Page migration allows a process to manually relocate the node on which its
25 Page migration functions are provided by the numactl package by Andi Kleen
28 which provides an interface similar to other NUMA functionality for page
31 proc(5) man page.
37 manual page migration support. Automatic page migration may be implemented
54 Page migration allows the preservation of the relative location of pages
60 Page migration occurs in several steps. First a high level
73 Calling isolate_lru_page() increases the references to the page
74 so that it cannot vanish while the page migration occurs.
76 the page.
80 how to allocate the correct new page given the old page.
84 the new page for each page that is considered for
90 migrate_pages() does several passes over its list of pages. A page is moved
91 if all references to a page are removable at the time. The page has
93 is increased so that the page cannot be freed while page migration occurs.
97 1. Lock the page to be migrated.
101 3. Lock the new page that we want to move to. It is locked so that accesses to
102 this (not yet up-to-date) page immediately block while the move is in progress.
104 4. All the page table references to the page are converted to migration
105 entries. This decreases the mapcount of a page. If the resulting
106 mapcount is not zero then we do not migrate the page. All user space
107 processes that attempt to access the page will now wait on the page lock
108 or wait for the migration page table entry to be removed.
111 to access the page via the mapping to block on the spinlock.
113 6. The refcount of the page is examined and we back out if references remain.
114 Otherwise, we know that we are the only one referencing this page.
117 page then we back out because someone else modified the radix tree.
119 8. The new page is prepped with some settings from the old page so that
120 accesses to the new page will discover a page with the correct settings.
122 9. The radix tree is changed to point to the new page.
124 10. The reference count of the old page is dropped because the address space
125 reference is gone. A reference to the new page is established because
126 the new page is referenced by the address space.
130 to sleeping on the locked new page.
132 12. The page contents are copied to the new page.
134 13. The remaining page flags are copied to the new page.
136 14. The old page flags are cleared to indicate that the page does
139 15. Queued up writeback on the new page is triggered.
141 16. If migration entries were inserted into the page table, then replace them
143 already waiting for the page lock.
145 17. The page locks are dropped from the old and new page.
146 Processes waiting on the page lock will redo their page faults
147 and will reach the new page.
149 18. The new page is moved to the LRU and can be scanned by the swapper,
152 Non-LRU page migration
162 page that it may be able to move. This uses the ``page->mapping`` field,
168 The following events (counters) can be used to monitor page migration.
170 1. PGMIGRATE_SUCCESS: Normal page migration success. Each count means that a
171 page was migrated. If the page was a non-THP and non-hugetlb page, then
172 this counter is increased by one. If the page was a THP or hugetlb, then
177 2. PGMIGRATE_FAIL: Normal page migration failure. Same counting rules as for